API Gateway Data Model and General Interaction Diagram
  • 20 Mar 2023
  • 1 Minute to read
  • Contributors
  • Dark
    Light
  • PDF

API Gateway Data Model and General Interaction Diagram

  • Dark
    Light
  • PDF

Beta version

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).

path and ID.png

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.

Paths within an API

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 Sequence.drawio.png

API Gateway interaction general workflow

The general workflow for API Gateway use can be described as follows:

  1. 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;
  2. The API administrator obtains a URL for calling the created path;
  3. A client sends a task to the provided URL;
  4. API Gateway receives the task and proxies it to Corezoid;
  5. 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.