Settings Tab
This section covers CORS, Cache, Error Response Templates, Forwarded IP Header Parameters and Log settings of the API Proxy.
If a warning appears on the settings saying "Global Settings is active" as shown in the image below, it indicates that this API Proxy is linked to a Global Settings configuration, and the settings on this panel are managed from within the API Proxy Settings.When you click on the warning, you will be taken to the relevant setting.
The image containing the Settings tab is below:
CORS Settings
CORS (Cross-Origin Resource Sharing) can be configured in this subsection.
The Configure button becomes active when this fields is activated and contains the relevant settings.
The picture below shows the CORS Settings:
The CORS Settings fields are shown in the table below.
Field | Description | |
|---|---|---|
Request Headers | Origin | It contains the origin (domain, protocol, port) information from which the preflight request is sent. |
| Access-Control-Request-Method | The HTTP method to be sent in the original request is specified. | |
| Access-Control-Request-Headers | The HTTP headers to be sent in the original request is specified. | |
| Access-Control-Max-Age | It is given in seconds how long the response of the preflight request will remain in the cache without sending another preflight request. | |
| Access-Control-Allow-Headers | Header values that API Proxy allows for access are entered. If Access-Control-Request-Headers is specified in the preflight request, this header is placed on the response. It contains information about which HTTP headers can be used in the original request. | |
| Access-Control-Allow-Methods | It contains the HTTP methods that are allowed when accessing the server. The methods that API Proxy allows for access are selected from the list by ticking:
| |
Response Headers | Access-Control-Allow-Origin | Origin values allowed by API Proxy are entered. If * is entered in this field, all origins can send requests. |
| Access-Control-Allow-Credentials | In the original request, the value of whether the credentials are present is entered. | |
| Access-Control-Expose-Headers | Other headers that clients can access are entered. | |
You can visit the CORS Origin Values and CORS Headers pages to add new ones to the predefined Origin and Header values.
Cache Settings
By caching the responses returned from the API Proxy, requests of the client can be answered from the cache without sending them to the Backend API. You can manage this cache settings from here.
The picture below shows the Cache Settings:
The Cache Settings fields are shown in the table below.
| Field | Description |
|---|---|
| Cache only HTTP Get Requests (Sadece HTTP Get isteklerini Ön belleğe Al) | When this option is enabled, only responses to HTTP GET requests are cached. |
| Cache Key Type (Önbellek Anahtar Tipi) | Options for defining the cache key: • Use Query Params (Query Parametreleri Kullan): Uses HTTP query parameters from the incoming request to generate the cache key. Example: if the request is /method?param1=value1¶m2=value2, the cache key is derived from param1=value1¶m2=value2, and responses are cached accordingly.• Create Custom Key (Özel Anahtar Oluştur): Allows creating a cache key using selected fields from the request. When selected, fields defined in the “Variable List” section are combined to generate the cache key. |
| Capacity (Kapasite) | Maximum number of responses that can be stored in the cache. This field is mandatory. |
| Invalidation Requires Authn (Önbellek Geçersizleme için Yetki Gerekir) | When the requester sends one of the following Cache-Control header values: no-cache, no-store, or max-age=0, the current cache can be invalidated. Enable this option if authentication is required to invalidate the cache. |
| Handling Action (Yetkisiz İsteklerin Ele Alınması) | Action to take when cache invalidation is attempted without proper authorization: • Continue (Devam Et): If selected, the request continues even if no-cache, no-store, or max-age=0 is received without authorization.• Stop (Dur): If selected, when one of the values no-cache, no-store, or max-age=0 is received without authorization, the process is stopped and an error response is returned.This field becomes active only if Invalidation Requires Authn is enabled. |
| Storage Type (Depolama Tipi) | Defines where the cache data will be stored: • Local: Cache data is stored in the local Gateway node. • Distributed: Cache data is shared and synchronized across all Gateway nodes. This field is mandatory. |
| TTL - seconds (TTL (saniye)) | Time in seconds during which the cached response remains valid. This field is mandatory. |
| Cache Null Value (Null/Boş Değerleri Ön belleğe Al) | Enable this option if empty or null responses should also be cached. |
Sending 'no-cache' to the Cache-Control header allows the current cache to be made refreshable.
Customizing the XML Error Response Template
It is used to prepare response templates that will be used when any error is returned from the API Proxy to the client.
When any template is activated, the default template is displayed and can be customized if desired.
The Configure button becomes active when this fields is activated and contains the relevant settings.
The picture below shows the XML Error Response Template:
The XML Error Response Template fields are shown in the table below.
Field | Description |
|---|---|
Permit Special Chars in Response Message | Special characters that may be present in the error message of the response can corrupt the XML message structure. Determines whether these are allowed or not. |
XML Value | The error template of XML type can be edited in this field. |
Content Type | The content type of the response to be returned. |
Customizing the JSON Error Response Template
The Configure button becomes active when this fields is activated and contains the relevant settings.
The picture below shows the JSON Error Response Template:
The JSON Error Response Template fields are shown in the table below.
Field | Description |
|---|---|
Permit Special Chars in Response Message | Special characters that may be present in the error message of the response can corrupt the JSON message structure. Determines whether these are allowed or not. |
JSON Value | The JSON type error template can be edited in this field. |
Content Type | The content type of the response to be returned. |
Within the response templates, the values in the form #...# are used as placeholders to put the relevant part of the error message. Placeholders and their descriptions are in the following table:
| Placeholder | Description |
|---|---|
| #CORRELATIONID# | Apinizer creates a unique key for each incoming request so that the request can be tracked throughout the flow. By using this key, for example, it becomes possible to follow the log records of the applications by associating them with the log records on Apinizer. |
| #FAULTCODE# | Specifies where to put the error code to be returned to the client in the response message. |
| #FAULTMESSAGE# | Specifies where to place the error message returned to the client in the response message. |
| #FAULTMESSAGE_FIRSTLINE# | The first line or first 150 characters of the error message to be returned to the client are taken and put in the response message. |
| #FAULTSTATUSCODE# | Specifies where to put the HTTP Status Code returned to the client in the response message. |
| #RESPONSEFROMAPI# | If there is a response returned from the Backend API, it determines where the response will be placed in the response message to be returned to the client. |
| #RESPONSEFROMAPI_FIRSTLINE# | The first line or first 150 characters of a response returned from the Backend API are taken and put into the response message to be returned to the client. |
Both templates can be activated if desired. If both templates are active, which one will be used is decided according to the following criteria:
- If the value of the Content-Type header specifies the JSON format, the JSON Error Response Template is used.
- If the Content-Type header is empty and the API Proxy's type is REST, the JSON Error Response Template is used.
- If these are not valid, the XML Error Response Template is used.
If both templates are not activated or the cause of the error is API Proxy not found (address may be wrong, API Proxy may not be deployed), following response returns with text/plain;charset=utf-8 header:
[#CORRELATIONID#],[#FAULTCODE#],[#FAULTMESSAGE#],[#FAULTSTATUSCODE#],[#RESPONSEFROMAPI#]
If the "Ignore Error Response Template In Case Of Error On Backend API" option is selected in the Routing tab of the API Proxy, the templates defined in this section are not used, and the error response of the Backend API is sent to the client as it is.
Forwarded IP Header Setting
If the API Proxy is behind a Load Balancer or Proxy Server, the IP value of the client cannot be known by the API Proxy or Backend API, since the request from the client will be directed to the API Proxy by this layer. Therefore, Load Balancers or Proxy Servers can transmit the original client's IP with a header. The Forwarded IP Header Parameters setting ensures that the client IP is accessible by the API Proxy and Backend API by specifying the name of this header, which can vary by software/hardware.
The picture below shows the Forwarded IP Header Setting:
The Forwarded IP Header Setting fields are shown in the table below.
Field | Description |
|---|---|
Forwarded IP Header Parameter | If the client is behind a Load Balancer or a API Proxy, this parameter is used in order to access the real IP of the client. |
IP to Use | If the request has passed more than one proxy, more than one IP address can accumulate in the XFF value. In this case, IP to Use decides which address to get. |
Hiding API Definition File
When enabled, users are prevented from accessing the API Definition file via the API Proxy's external access address. However, this setting has no effect for definition files viewed through the API Manager.
If the API Proxy is in a Proxy Group and the Definition File is closed, the definition file of the API Proxy stored in the Proxy Group Definition File will not appear, if the definition files of all the Proxies in the Proxy Group are closed, the user will get an access error.
You can visit the Overview Tab page to access API Proxy Definition files.
API Maintenance Mode
The Maintenance Mode feature, when enabled, will return a message indicating that the API is currently under maintenance. The API responds with a predefined HTTP status code and message structure.
The image below shows the configuration screen for Maintenance Mode settings:
The fields used for configuring Maintenance Mode settings are shown in the table below.
| Field | Description |
|---|---|
| HTTP Status Code | The default HTTP status code. |
| Message | The message template can be edited in this field. |
| Content Type | The content type of the response to be returned. |
API Traffic Log Settings
Request and response messages coming to API Proxy are logged by sending them to API Proxy Traffic Log Connectors in the environment where API Proxy is deployed.
Log records contain two types of data:
- The first of these is metric data. Storing metric data is not optional.
- The second is the content that consists header, parameter and body fields of the request and response messages in these 4 regions: Client → API Proxy, API Proxy → Backend API, Backend API → API Proxy, API Proxy → Client. Which of these fields will be included in the log records can be determined according to the need or based on the resource consumption of the log server.
By default, log fields in all message zones of the project are active. Although all log fields are active by default, it is recommended to disable Body fields so that the log data does not overgrow, especially in Production Environments.
The picture below shows the Log Settings tab:
The fields used for log settings are shown in the table below.
| Field | Description | |
|---|---|---|
Header | Enables logging the Header values for the relevant region. | |
Body | Enables logging the content of the Body for the relevant region. | |
Parameter | Enables logging the Parameter values for the relevant region. | |
Connectors | It is used to select which connector the relevant logs will be sent to. | |
In the Log Settings section, log settings are managed for the relevant API Proxy only.
For detailed information about the log settings, you can visit the API Traffic Log Settings page.