[Yandex Cloud documentation](../../index.md) > [Yandex API Gateway](../index.md) > Concepts > Resource relationships

# Resource relationships in API Gateway

An _API gateway_ is an interface for working with services in Yandex Cloud or on the internet.

API gateways are set in a declarative way using specifications. A specification is a JSON or YAML file with an API gateway description based on the [OpenAPI 3.0](https://github.com/OAI/OpenAPI-Specification) standard. In API Gateway, the specification includes extensions for integration with other cloud platforms.

Available extensions:
* [Static response](extensions/dummy.md)
* [Access over HTTP](extensions/http.md)
* [Integration with Cloud Functions](extensions/cloud-functions.md)
* [Integration with Serverless Containers](extensions/containers.md)
* [Integration with Smart Web Security](extensions/sws.md)
* [Integration with Object Storage](extensions/object-storage.md)
* [Integration with DataSphere](extensions/datasphere.md)
* [Integration with Data Streams](extensions/datastreams.md)
* [Integration with Message Queue](extensions/ymq.md)
* [Integration with YDB](extensions/ydb.md)
* [Integration with Swagger UI](extensions/swagger.md)
* [Greedy parameters](extensions/greedy-parameters.md)
* [Generic HTTP method](extensions/any-method.md)
* [Authorization using a Cloud Functions function](extensions/function-authorizer.md)
* [Authorization using a JWT](extensions/jwt-authorizer.md)
* [WebSocket protocol support](extensions/websocket.md)
* [Data validation](extensions/validator.md)
* [CORS support](extensions/cors.md)
* [Specification parameterization](extensions/parametrization.md)
* [Canary release](extensions/canary.md)
* [Request rate limit](extensions/rate-limit.md)
* [Response code replacement](extensions/status-mapping.md)
* [Transformation of response and request bodies](extensions/schema-mapping.md)

## Algorithm for a handler search in the OpenAPI specification {#algorithm}

When searching for a handler, API Gateway does the following:
1. Selects in the OpenAPI specification the routes that fall in with the request being processed.
1. Sorts the selected routes by priority:
    * The highest priority is given to fixed routes, which do not contain path parameters and [greedy parameters](extensions/greedy-parameters.md), e.g., `/simple/path`.
    * Routes that contain path parameters but do not have any greedy parameters get the medium priority, e.g., `/{param}/path`.
    * The lowest priority is given to routes with greedy parameters, e.g., `/{greedy_param+}`.

    If two routes have the same priority:
    * Two routes with medium priority are consistently compared across URL segments. There are two types of segments: fixed (e.g., `simple`) and parameterized (e.g., `{param}`). A fixed segment has a higher priority than a parameterized one. If all route segments have the same priority, the longer route is selected.
    * If two routes have the lowest priority, the longer one is selected.

### Examples of route comparison

{% cut "`/a/{param1}/b` and `/a/{param2}/{param3}`" %}

Both routes have medium priority because they contain path parameters, but do not contain greedy parameters, so they are consistently compared across URL segments.

1. The `a` and `a` segments are both fixed and have the same priority.
1. The `{param1}` and `{param2}` segments are both parameterized and have the same priority.
1. The `b` segment is fixed and the `{param3}` segment is parameterized, so the `b` segment is selected.

Thus, `/a/{param1}/b` is selected as a handler.

{% endcut %}

{% cut "`/a/b/{param1}` and `/a/{param2}/d`" %}

Both routes contain path parameters but do not contain greedy parameters, so they have medium priority and are consistently compared across URL segments.

1. The `a` and `a` segments are both fixed and have the same priority.
1. The `b` segment is fixed and the `{param2}` segment is parameterized, so the `b` segment is selected.

Thus, `/a/b/{param1}` is selected as a handler.

{% endcut %}

{% cut "`/a/b/{param+}` and `/a/{param2}/d`" %}

The `/a/b/{param+}` route contains a greedy parameter, which means it has the lowest priority. The `/a/{param2}/d` route contains a path parameter, but does not contain a greedy parameter, so it has medium priority. Out of the medium and lowest-priority routes, the route with the medium priority is selected.

Thus, `/a/{param2}/d` is selected as a handler.

{% endcut %}

{% cut "`/a/{param}` and `/a/{prm}`" %}

Both routes contain path parameters but do not contain greedy parameters, so they have medium priority and are consistently compared across URL segments.

1. The `a` and `a` segments are both fixed and have the same priority.
1. The `{param}` and `{prm}` segments are both parameterized and have the same priority.

Since it is not possible to select a route based on segments, the route lengths are compared. The `/a/{param}` route is longer than the `/a/{prm}` route.

Thus, `/a/{param}` is selected as a handler.

{% endcut %}

{% cut "`/a/{param1}/{param+}` and `/a/{param2}/{prm+}`" %}

Both routes contain greedy parameters, so they have the lowest priority and their lengths are compared. The `/a/{param1}/{param+}` route is longer than the `/a/{param2}/{prm+}` route.

Thus, `/a/{param1}/{param+}` is selected as a handler.

{% endcut %}

## Using domains {#domains}

API Gateway allows you to add your custom domain to access the API gateway. To establish a TLS connection, you can use certificates added in Certificate Manager.

For more information on connecting your custom domain to the API gateway, see [Adding a domain](../operations/api-gw-domains.md).

For more information about adding certificates, see [Adding a Let's Encrypt® certificate](../../certificate-manager/operations/managed/cert-create.md).

## Authorization {#authorization}

API Gateway enables you to implement common [authentication and authorization algorithms](https://swagger.io/docs/specification/authentication/) as described in the [OpenAPI 3.0](https://github.com/OAI/OpenAPI-Specification) specification. Currently, you can use [authorization using a function](extensions/function-authorizer.md) and [using JWT](extensions/jwt-authorizer.md).

## WebSocket {#websocket}

{% note info %}

This feature is in the [Preview](../../overview/concepts/launch-stages.md) stage.

{% endnote %}

For two-way asynchronous communication between clients and an API gateway, API Gateway supports the [WebSocket](https://en.wikipedia.org/wiki/WebSocket) protocol. Clients can send messages to an API gateway, which in turn can independently send messages to client applications. This means clients can receive data without having to make an HTTP request. Web sockets are often used in apps that require real-time data updates, such as messengers and online chats, multiplayer games, collaboration tools, trading apps, and sports betting services.

To connect to an API gateway using WebSocket, you can use a service domain allocated when creating the API gateway or any other domain added to the API gateway.

Integrations are supported for the following events:
* Opening a connection.
* Sending messages via a web socket.
* Closing a connection.

To set up integrations, you can use [special extensions](extensions/websocket.md) in the OpenAPI specification.

You can manage web sockets using the [API](../api-ref/websocket/authentication.md) that receives information about a connection, sends data to the client side, and closes the connection.

For limits related to WebSocket support, see [Quotas and limits](limits.md).

To view an example of a serverless WebSocket app, [click here](http://github.com/yandex-cloud-examples/yc-serverless-game).
 
#### Useful links {#see-also}

* [Overview of available extensions](extensions/index.md)