Settings Tab
This section covers CORS, Cache, Error Response Templates, Forwarded IP Header Parameters and Log settings of the API Proxy.
The picture below shows the Settings Tab:
If there is a warning on the settings as "Proxy Group Settings Enabled" in the image below, it means that the API Proxy is connected to an API Proxy Group and the settings in this panel are managed within the API Proxy Group.
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 | If this option is selected, only HTTP Get requests' responses will be cached. | |
| Cache Key Type | There are two options for Cache Key Type:
For example, when the query parameter is /methodName?param1=value1¶m2=value2, the key to be kept in the cache consists of the value "param1=value1¶m2=value2"
When this value is selected, a key is created with the fields to be specified in the "Variable List" table. | |
| Variable List | If Create Custom Key is selected as the Cache Key Type, this field becomes active. This list specifies where to retrieve the relevant values in the header, parameter, or body sections of the request message that will be used to generate the cache key. For example; An expression can be written as "Create key based on the APIKEY value in the header of the request message and the XPath value "//identity_no" in the body". | |
| Capacity | Maximum number of the responses to be cached. | |
Invalidation Requires Authn | Selected if authorization is required to invalidate the cache. | |
Handling Action | If authorization is required to invalidate the cache, the action to take for unauthorized requests is selected:
| |
TTL | The length of time the cached response will remain in the cache. It is given in seconds. | |
| Cache Null Value | Checked if null values are also to be cached. | |
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 Management Console.
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 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.