Skip to main content
With Apinizer, it is very easy to create an API Proxy using an existing API/Web Service as Backend API or to create an API Proxy without Backend API and offer it as an API. In this section, how an API Proxy can be created using the URL information of an API in Swagger 2.x format will be shown, and details of related options and data fields will be explained.
Quick Start The steps followed when creating an example API Proxy below are the same as those described on the Quick Start page, but this section contains explanations about data fields.

API Proxy Creation Steps

1- Development → API Proxies item is selected in the main menu. 2- The +Add API Proxy button at the top right of the opened interface is clicked. API Proxy Creation Button 3- The following options are seen for the API Proxy to be newly created. API Proxy Tip Seçenekleri

API Proxy Types

The appropriate type is selected for the API Proxy to be created. Existing API Proxy types are described in the table below.
TypeDescription
Swagger 2.xUsed to create REST API Proxy from Swagger 2.x definition. For detailed information click here.
WSDL (SOAP)Used to create SOAP API Proxy from WSDL definition. For detailed information click here.
OpenAPI/Swagger 3.0.xUsed to create REST API Proxy from OpenAPI/Swagger 3.0.x definition. For detailed information click here.
Reverse ProxyUsed to create HTTP Reverse Proxy. It forwards incoming requests to the Backend API regardless of whether there is a related method/endpoint, and returns responses returned from the Backend API to the client. No specification file is needed and there is no need to define the Backend API’s methods/endpoints one by one. It is sufficient to provide the Backend API’s root context.
No-Spec APIProvides the ability to manually define methods/endpoints and create API Proxy for an API that was previously developed with code-first approach and has no specification file. Apinizer automatically creates API specification files in Swagger or OpenAPI formats according to the definitions.
gRPCUsed to create gRPC Proxy that forwards incoming gRPC requests to Backend gRPC Server and returns responses returned from Backend gRPC Server to the client. No specification file is needed, but proto file can be used.
WebSocketUsed to create WebSocket Proxy.
ConnectorProvides the ability to create API proxy from connectors. This feature enables converting HTTP to different protocols (such as Kafka, RabbitMQ, ActiveMQ, Mail… etc.). To learn more about connectors, please visit this page.

API Specification Document Source

Some additional options are also seen below the options.
FieldDescription
Enter URLThe URL where the API Specification document of the API for which an API Proxy will be created is accessible is known. API Proxy can be created by specifying this URL. Examples: https://petstore.swagger.io/v2/swagger.json, http://www.dneonline.com/calculator.asmx?WSDL
Upload FileIf the API Specification document of the API for which an API Proxy will be created is saved as a file on the user, API Proxy can be created by uploading this file.
Select API SpecFor the API for which an API Proxy will be created, API Proxy can be created using an API Specification Document previously created with the API Specification Document Editor (API Spec Creator).
The appropriate type and option is selected for the API Proxy to be created. For this example, the Enter URL link of the Swagger 2.x type is clicked. Swagger URL Seçimi 4- The following data fields are found in the incoming interface. Spec Authorization Form
FieldDescription
Use Spec Authorization_Some specification files check that the client is authorized to view their content. For this, authentication data must be sent in the HTTP request. If the specification file at the URL to be accessed is such a file, this box is marked and credentials are entered.
URLThe address where the specification file will be accessed.
If the Use Spec Authorization option is marked, the following table appears and keys required for authorization are added. Spec Authorization Keys For this example, the Use Spec Authorization option is not needed. The address https://petstore.swagger.io/v2/swagger.json is written in the URL field and the Parse button on the right is clicked. URL Parse Form 5- The Swagger file at the address given in the URL field is parsed and the API’s information is displayed. API Proxy Form Filled The fields in the incoming interface are described in the table below.
FieldDescription
NameThe name given to the API Proxy by the user. This name appears in interfaces.
DescriptionThe definition information of the API Proxy.
Routing AddressesAccess addresses of the Backend API. Can be activated/deactivated with Status checkbox. Multiple addresses can be added for load balancing.
Client RouteThe routing method (Path, Method, or Header based) that clients will use to access the API Proxy.

Relative Paths:
A part of the address where the API Proxy is opened for access. Used to route incoming requests to the appropriate API Proxy.

Example:
• Apinizer address: https://demo.apinizer.com
• Relative Path: /petstoreProxy
• Environment address: /apigateway
• Endpoint: /findByStatus
• Full access address: https://demo.apinizer.com/apigateway/petstoreProxy/findByStatus

Things to note:
• Must be unique at application level
• Cannot be the beginning of another path
• If Enable Relative Path is active in project settings, project path is automatically added to the front

For gRPC: If the API Proxy type is gRPC, this value should be in the form “/packagename.servicename” in the proto document. For example, if you have a proto file like below, the relative path value should be “/hello.HelloService”:
proto<br/>syntax = "proto3"<br/>package hello;<br/>service HelloService {<br/>}<br/>

For WebSocket: If the API Proxy type is WebSocket, you can visit this page regarding how the relative path value should be entered.

Methods:
HTTP methods (GET, POST, PUT, DELETE, PATCH, etc.) supported by the API Proxy.

Hosts:
Host addresses of Backend services. New addresses can be added with “Add a host”.

Headers:
HTTP headers to be added at API Proxy level. New headers can be added with “Add a header”.

For detailed information see: API Proxy Client Route Usage Guide
Backend API VersionThe Backend API Version defined for the API Proxy.
Category ListCategories can be created to facilitate management of API Proxies. Category list is used to determine which categories the API Proxy belongs to.
UsageSpecifies who the source of the Backend API is. Values it can take: Publisher: Backend API has been opened by the company/institution itself. Consumer: Backend API belongs to another company/institution. API Proxy is being created to access that API. Publisher & Consumer: API Proxy created for a Backend API belonging to another company/institution is being created to be used by third parties as well.
Sharing TypeSpecifies how the Backend API will be shared. Values it can take: External, Internal, External and Internal