-
Print
-
DarkLight
-
PDF
API Gateway Data Model and General Interaction Diagram
The product is currently in the Beta version and has limited availability and functionality
API Gateway data model
There are two entities in the API Gateway data model:
- API (endpoint);
- Path (resource).
A single API entity is a collection of paths. When created in API Gateway, each API gets an ID. An API ID is a unique string which identifies that the API in URLs is a part of FQDN (Fully Qualified Domain Name). For example, in the https://foo.example.com/bar/baz
URL, the foo
string is the API ID.
Path entities store information on target Corezoid processes and call parameters. Any API path is represented by a URL path. In the https://foo.example.com/bar/baz
URL, the /bar/baz
string is the path.
Every path must be unique within its API
This design enables using, for example, different request methods when sending tasks to the same process.
API Gateway interaction diagram
API Gateway interaction general workflow
The general workflow for API Gateway use can be described as follows:
- An API administrator creates an API entity (endpoint) and a path entity (resource) attached to it, and provides the required information: target process ID and call parameters;
- The API administrator obtains a URL for calling the created path;
- A client sends a task to the provided URL;
- API Gateway receives the task and proxies it to Corezoid;
- If the called path is Synchronous, API Gateway waits for the task processing result from Corezoid;
If the called path is Asynchronous, API Gateway responds to the client with the 204 status as soon as the task is accepted by Corezoid.