Introduction
API Gateways are expected to act upon request messages while they are forwarded to the backend APIs, and upon response messages when they are returned back to the API caller applications. Any actions applied to API messages may be called Messages Processing.
More generically, Messages Processing can be thought of as a configurable sequence of tasks executed by an API Gateway while it handles request and response messages. A high-level list of the message processing tasks is below:
- Enforcing Authentication of incoming request messages (Inbound Security)
- Enforcing Authorization of incoming request messages (Inbound Security)
- Transforming the content of messages such as content injection, removal, or replacement.
- Implementing workflows in Messages Processing:
- Workflows may include conditional execution of certain actions based on the identity of a caller, message content, usage of cached information (for example cached security tokens), and many other criteria.
- Workflow may include calls to external API(s), whose responses may be used to modify the originally received request. For example, an API gateway may be configured to make an API call to some external service for a security token, which must be then included in the originally received request before it is forwarded to the backend API.
- Implementing Response caching
- Custom Messages Processing when customers need to extend an API Gateway with extra capabilities. Custom Messages Processing may also include integrations with third-party systems.
- Implementing outbound security of the request messages forwarded to the backend APIs. For example, an API Gateway may be configured to implement an OAuth/OpenID Connect secure call to a backend API with injected security token.
- Implementing configurable logging/recording of the request and response messages and their context such as identities of the caller, request/response durations, message sizes, etc.
Figure. Messages Processing inside an API Gateway
Authentication and Authorization tasks are executed as part of an Inbound Security for a request message before any message transformations or workflows, which means tasks 1 and 2 from the list above always happen before tasks 3,4,5 or 6. Implementing Outbound Security (task 7) always happens just before the request message is sent on a wire to a backend API. Logging and recording (task 8) can happen anywhere while messages are processed by an API Gateway.
At a high level, the diagram above applies to any API Gateway from any vendor. The difference is always about how easy Message Processing tasks are configured, and how easy to understand and manage these configurations. In practice, the complexity is driven by two criteria:
- Using declarative vs. imperative configurations.
- Using individual configurations of isolated tasks vs. combining multiple tasks’ configurations in a single unit.
Note, that I do not account here for the complexity and capabilities of the Message Processing tasks assuming we are comparing configurations of the tasks with the same or very similar capabilities.
Declarative vs. Imperative configurations
Message Processing tasks can be configured either declaratively or imperatively. The declarative configurations describe only the desired results. They are easier to read, understand, and manage via simple UI screens. The imperative configurations specify the sequence of steps that provide details of how a task is executed. Imperative configurations are typically not as simple as declarative, but they offer more control. They are usually done via code, script, or a sequence of UI blocks representing execution steps. The more things can be configured declaratively, the easier it is to use and understand an API Management product.
Isolated vs. Combined configurations
There are API Management products that combine all of the message processing tasks in a single API “policy” making it hard to read, understand and maintain, while it is easier to locate them. Other products offer separate configurations (different User Interface screens) for all or some tasks, making them easier to understand and manage, especially if configured declaratively.
Sentinet Message Processing configurations
Sentinet API Management from Nevatech not only makes a clear distinction of the nature of the Message Processing tasks but also requires administrative users to work with separate User Interface screens for various tasks’ configurations. Treating tasks of different natures in isolation from each other helps Sentinet users to better understand the entire, end-to-end process of configuring APIs in an API Gateway. Isolation of tasks also helps to better control access privileges to individual tasks by API Management users with different roles (for example changing security settings vs. changing logging settings or changing message transformations).
In the Sentinet API Management, we configure Message Processing tasks with the following screens:
1. Authentication (task 1) is configured in a Policy screen, which is used as part of an API’s Inbound Endpoint configuration. The endpoint’s policy is a configuration of the required security Policy authentication scheme only (so it is literary just an Authentication only). This task is configured entirely declaratively and in isolation from other tasks.
2. Authorization (task 2) is configured in the Access Control screen, which assigns one or more graphically designed Access Rules to an API in an API Gateway. This task is configured declaratively and in isolation from other tasks. 
Access Control Screen
Graphical Access Rules Designer Screen
3. Message transformations, request and response processing workflow, caching and many other related tasks (similar to tasks 3,4,5 and 6) are configured in the Processing screen using a graphical drag-and-drop UI Designer.
The Processing screen also includes Settings sub-screen, which defines “static” API behaviors unrelated to workflow’s actions execution order, for example support for CORS , pass-through rules for HTTP Headers, some generic errors handling settings and few others.
Sentinet’s Processing screen represents a mix of declarative and imperative configurations. On one hand it is an imperative configuration, because it clearly shows the sequence of how message processing steps are executed (not to mention that some workflow processing blocks can be configured with typing a regular C# .NET code compiled “on-a-fly”). On the other hand, this configuration is declarative because the Designer is still very much graphical, and its message processing blocks are typically configured declaratively through simple UI dialog boxes.
Processing task is configured entirely in isolation from other tasks.
4. Outbound Security (task 7) is configured in a Policy screen, which is used as part of an API’s Outbound Endpoint configuration. Endpoint’s policy is a configuration of the authentication mechanism with optional Outbound Client Identities configuration, such as Username/Password, X.509 client certificate or OAuth Client Credentials. This task is configured entirely declaratively and in isolation from other tasks.
5. Messages Logging and Recording is configured graphically in the Monitoring Control Screen. Sentinet API Gateway creates logs with monitoring data asynchronously from the actual request/response processing, which ensures that Sentinet monitoring does not slow down API calls. This task is configured entirely declaratively and in isolation from other tasks.
As you can see, Sentinet uses predominantly declarative and isolated configurations with imperative configurations injected only when they are absolutely needed for advanced scenarios.
By segregating API Gateway’s Message Processing tasks and their UI configurations, Sentinet users have better understanding of the different stages and aspects of managing API calls. Moreover, most often all configurations are done through a few simple UI screens without any code or scripts involved.