Creating an API Proxy
With Apinizer, it is very easy to create an API Proxy using an existing API/Web Service as a Backend API, or create an API Proxy without a Backend API and publish it as an API.
In this document, creating an API Proxy using the Swagger 2.x Documentation URL of an API will be used to explain related fields.
The steps followed when creating a sample API Proxy below are the same as those described on the Quick Start page, but there are explanations for the data fields in this section.
1- Development → API Proxies is selected in main menu.
2- Click the +Create button at right top side of the interface.
3- Options to create the API Proxy will be displayed.
Type | Description |
---|---|
Swagger 2.x | It is the widely used API Definition File standard for the REST protocol. Click here for more information. |
WSDL (SOAP) | It is the Web Service Definition File standard of the SOAP protocol. Click here for more information. |
OpenAPI/Swagger 3.0.x | It is an API Definition File standard created after Swagger for the REST protocol. Click here for more information. |
Reverse Proxy | It is used to send incoming requests to a Backend API regardless of whether there is such a method/endpoint, and return the responses returned from the Backend API to the client. There is no need for a definition file, and there is no need to define the methods/endpoints of the Backend API one by one. It is sufficient to give the root context of the backend API. |
No-Spec API | Provides ability to manually define the methods/endpoints of and create create an API Proxy for an API which was previously developed in code-first approach and has no definition file. Apinizer automatically generates API definition files in Swagger or OpenAPI formats according to the definitions. |
Connector | Provides ability to create API proxy from connectors. This feature transforms HTTP to protocol of API to related connector's protocol such as Kafka, RabbitMQ, ActiveMQ, Mail...etc. To learn more about connectors please visit this page. |
KPS | KPS is a system that enables public institutions and other legal entities to access personal population and residence information held by the General Directorate of Population and Citizenship Affairs in an up-to-date and secure manner, 24/7, online. Only authorized clients can access the services of this system. The fact that the services are WSDL-based and client configuration is complex, and that each client application within an institution must be provided with username/password information, poses challenges for institutions. The ability to create an API Proxy of the KPS type provides significant convenience by enabling centralized management of this username/password pair and automatically handling the client details for accessing KPS services. Click here for information on activating the KPS option. |
There are some additional options below the options.
Field | Description |
---|---|
Enter URL | API Proxy can be created by specifying the URL where the API Definition Document of the API for which API Proxy is to be created is accessible. Examples: |
Upload File | API Proxy can be created by uploading the API Definition Document of the API for which API Proxy is to be created is accessible. |
Select API Spec | API Proxy can be created by an API Spec that was previously created with the API Spec Creator. |
Click the Enter URL link for Swagger 2.x from the options in the New API Proxy creation interface.
4- Following data fields appear on the interface.
Field | Description |
---|---|
Use Spec Authorization | Some definition files check that the client is authorized so that their content can be viewed. For this, authorization data must be sent within the HTTP request. If the definition file in the URL to be accessed is such a file, this box is checked and the credentials are entered. |
URL | The URL of the API Definition Document. |
If the Use Spec Authorization option is checked, the table below appears and the keys required for authorization are added.
The Use Spec Authorization option is not needed for this example. Type the address https://petstore.swagger.io/v2/swagger.json in the URL field and click the Parse button on the right.
5- The information of the API is displayed by parsing the Swagger file at the address given in the URL field. The fields in the incoming interface are explained in the table below.
Field | Description |
---|---|
Name | The name given to the API Proxy by the user. This name is displayed in interfaces. |
Description | An optional brief description about the API Proxy. |
Addresses | Addresses that the Backend API is accessible. |
Relative Path | Relative Path is a part of the access URL of this API Proxy. The API Gateway's address is used to direct incoming requests to the appropriate API Proxy. For this, a unique address is created using the Relative Path for each deployed API Proxy, as in the example below:
While creating this value, some criteria should be considered;
|
Backend API Version | It is the Backend API version defined to API Proxy. |
Category List | Categories can be created to facilitate the management of API Proxies. The category list is used to identify which categories the API Proxy belongs to. |
Usage | Specifies the usage type of the Backend API. Options:
|
Sharing Type | Specifies how the Backend API will be shared. Options:
|
Check https://petstore.swagger.io/v2 within the Addresses part, and enter /petstoreProxy into the Relative Path textbox. Click the Save button on the top right of the screen to complete creating the API Proxy.