Message Processing and Policy Application

Documentation Index

Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Message Flow and Pipeline Structure

​

Client and Backend API

The flow between the client and Backend API is shown with the following elements:

• An arrow symbolizing the request message going from the client to the Backend API
• An arrow symbolizing the response message going from the Backend API to the client
• Icons showing the policies applied on request or response messages and the application order

Client: Shown in the frame on the left side of the interface. It is the stakeholder that sends requests to the API Proxy. It starts the flow. The message from the client reaches the Backend API after policies are applied. Backend API: The original API that is closed to direct access from the client and hidden from the client, receives requests from the API Proxy and returns responses to the API Proxy. Shown with the frame on the right side of the interface. The Backend API’s response is sent to the client after policies are applied. When the API link in the Backend API box is clicked, the Backend API’s API Definition Document is displayed.

​

Request Pipeline

Request Pipeline is the pipeline where requests from clients are processed before being sent to the backend.

​

Request Pipeline Flow

Request Pipeline consists of the following stages:

1. Pre-flow Policies: Security and validation
2. Conditional Policies: Conditional operations
3. Routing Step: Routing to backend

​

Response Pipeline

Response Pipeline is the pipeline where responses from the backend are processed before being sent to the client.

​

Response Pipeline Flow

Response flow is processed in the following order:

1. Post-flow Policies (Response): Response transformation
2. Conditional Policies: Conditional operations
3. Logging: Operation record (Asynchronous)
4. Client Response: Response to client

​

Error Pipeline

Error Pipeline is the pipeline where error conditions are processed. Error Pipeline comes into play when an error occurs in the Request or Response pipeline.

​

Error Pipeline Flow

In error conditions, the following flow is followed:

1. Fault Handler Policies: Error handling policies
2. Error Transformation: Error message transformation
3. Error Logging: Error record
4. Error Response: Error response to client

​

Policy Execution Order in Error Conditions

Policies to be executed in error conditions are added with the “Add Error Policy” option. If there is an error at any point in the flow, the normal flow is interrupted and first, if available, the error response template is applied to the error message. Then, policies added to the “Error Policies” line are executed from right to left in order.

​

Conditional Policy Execution

Policies can be executed conditionally. Conditional policy execution enables applying different policies based on message content, header values, query parameters, IP address, time-based conditions, or system variables. For detailed information about conditional policy execution, you can refer to the Conditional Policy Execution page.

​

Policy Management

Policies are configurations made to describe operations such as security, message filtering, validation, transformation or enrichment, partial business logic implementation, error management, etc., to be performed on request and response messages. The API Gateway executes the policies introduced to it with these configurations during the message flow between the Client and Backend API.

​

Policy Location and Execution Order

Policies can be added at 3 different points:

• API Proxy Group
• API Proxy
• Method/Endpoint

A policy added to an API Proxy Group is executed only if the request came through the API Proxy Group. A policy added to an API Proxy is executed for all methods/endpoints of that API Proxy. A policy added to a method/endpoint is executed only for that method/endpoint. The following visual shows an example of policies added to all 3 points. The visual shows that the API Proxy with the selected method/endpoint named GET - findByStatus is added to an API Proxy Group named Proxy Group - 1. The marked areas are the places where policies are displayed depending on where they are added:

• The area marked with frame 1 shows policies added for all methods/endpoints of this API Proxy, valid for all methods/endpoints, and to be applied to request messages. The text All indicates this.
• The area marked with frame 2 shows policies valid for the selected method/endpoint and to be applied to request messages.
• The area marked with frame 3 shows policies valid for the selected method/endpoint and to be applied to response messages.
• The area marked with frame 4 shows policies added for all methods/endpoints of this API Proxy, valid for all methods/endpoints, and to be applied to response messages. The text All indicates this.

If any policy is added for any method/endpoint of the API Proxy, a gear icon appears next to the method/endpoint. If no specific method/endpoint of the API Proxy is selected (or All is selected), 2 regions appear as shown in the following visual.

• The area marked with frame 1 shows policies added for all methods/endpoints of this API Proxy, valid for all methods/endpoints, and to be applied to request messages.
• The area marked with frame 2 shows policies added for all methods/endpoints of this API Proxy, valid for all methods/endpoints, and to be applied to response messages.

​

Policy Execution Order

Policies are executed in the message flow order:

• For request messages: API Proxy Group → API Proxy → method/endpoint in order
• For response messages: method/endpoint → API Proxy → API Proxy Group in order

At each level, policies at that level are processed according to the message flow direction order. The following visual summarizes this situation, showing the policy processing order numbered.

​

Adding Policy to Flow

To add a policy:

​

Updating Policy in Flow

When an existing policy’s icon is clicked, a window opens where that policy’s information can be updated.

​

Activating/Deactivating Selected Policy

A policy can be temporarily removed from use without being deleted from the method/endpoint or API Proxy where it was added. For this, the policy is opened for update and the Deactivate button at the top of the opened window is clicked.

​

Activating/Deactivating All Policies

In the method/endpoint section, the Disable All Policies link appears at the bottom of the middle section. When this link is clicked, if All option is selected, all policies added to the API Proxy; if in any method, only all policies added within that method are disabled. Disabled policies can be reactivated individually from the policy update window later or collectively by clicking the Activate All Policies link. When policies are disabled, the icons’ colors change to a gray appearance.

​

Removing Policy from Flow

When the mouse is hovered over the policy to be deleted, an icon appears that will delete the policy. The policy can be deleted by clicking this icon.

​

Policy Application Examples

​

Example 1: Simple Message Processing

​

Example 2: Conditional Policy Application

​

Example 3: Policy Application in Error Condition

​

Best Practices

​

Next Steps