Resource relationships in API Gateway
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
Available extensions:
- Static response
- Access over HTTP
- Integration with Cloud Functions
- Integration with Serverless Containers
- Integration with Smart Web Security
- Integration with Object Storage
- Integration with DataSphere
- Integration with Data Streams
- Integration with Message Queue
- Integration with YDB
- Greedy parameters
- Generalized HTTP method
- Authorization using a Cloud Functions function
- Authorization using a JWT
- WebSocket protocol support
- Data validation
- CORS support
- Specification parameterization
- Canary release
- Request rate limit
- Response code replacement
- Transformation of response and request bodies
Algorithm for searching the handler in the OpenAPI specification
When searching for the API Gateway handler:
-
It selects routes in the OpenAPI specification matching the request being processed.
-
It sorts the selected routes by priority:
- The highest priority is given to fixed routes, which do not contain path parameters and greedy parameters, such as
/simple/path
. - Routes that contain path parameters but do not have any greedy parameters get the medium priority. These are such routes as
/{param}/path
. - The lowest priority is given to routes with greedy parameters, such as
/{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.
- The highest priority is given to fixed routes, which do not contain path parameters and greedy parameters, such as
Examples of route comparison
/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.
- The
a
anda
segments are both fixed and have the same priority. - The
{param1}
and{param2}
segments are both parameterized and have the same priority. - The
b
segment is fixed and the{param3}
segment is parameterized, so theb
segment is selected.
The handler that is selected is /a/{param1}/b
.
/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.
- The
a
anda
segments are both fixed and have the same priority. - The
b
segment is fixed and the{param2}
segment is parameterized, so theb
segment is selected.
The handler that is selected is /a/b/{param1}
.
/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 middle and lowest-priority routes, the route with the middle priority is selected.
The handler that is selected is /a/{param2}/d
.
/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.
- The
a
anda
segments are both fixed and have the same priority. - The
{param}
and{prm}
segments are both parameterized and have the same priority.
Since it is impossible to select a route based on the segments, the route lengths are compared. The /a/{param}
route is longer than the /a/{prm}
route.
The handler that is selected is /a/{param}
.
/a/{param1}/{param+}
and /a/{param2}/{prm+}
Both routes contain greedy parameters, so they have the lowest priority and are compared in length. The /a/{param1}/{param+}
route is longer than the /a/{param2}/{prm+}
route.
The handler that is selected is /a/{param1}/{param+}
.
Using domains
API Gateway is integrated with the Certificate Manager domain management system.
You can use domains with confirmed rights when accessing the API. In this case, a certificate linked to the domain is used to provide a TLS connection.
For more information about domains, see Integration of the domain management system with Yandex Cloud services.
Authorization
API Gateway enables you to implement common authentication and authorization tools
WebSocket
Note
This feature is in the Preview stage.
For two-way asynchronous communication between clients and an API gateway, API Gateway supports the WebSocket
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, there are special extensions of the OpenAPI specification.
You can manage web sockets using the API 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.
To view an example of a serverless WebSocket app, click here