You can configure an actual backend or specify the implementation inline. You can also deploy this API as a prototype.
An endpoint defines the external destination for an outgoing message.
WSO2 API Manager has support for a range of different endpoint types allowing the API Gateway to connect with advanced types of backends. The API Manager supports HTTP endpoints, URL endpoints (also termed as address endpoint), WSDL endpoints, Failover endpoints, Load-balanced endpoints.
Also see Adding an Endpoint section in the ESB docs for details of the advanced configuration options.
|Production/Sandbox URLs||Endpoint of the back-end service URL and |
The system reads gateway endpoints from
If both types of endpoints are defined, the HTTPS endpoint will be picked as the server endpoint.
You cannot call back-end services secured with OAuth through APIs created in the API Manager. At the moment, you can call only services secured with username/password.
The API Manager allows you to expose both REST and SOAP services to consumers through APIs.
|Endpoint Security Scheme|
Secured endpoint or Non secured endpoint. Default is non secured endpoint.
If secured endpoint is selected, user is asked for credentials of the backend service.
If you get a
This parameter verifies the hostname of the certificate of a server when API Manager acts as a client and does outbound service calls.
URL of WSDL file describing API interface. (E.g.,
When you provide the WSDL URL, the WSDL content will be saved as a resource file under
|WADL||URL to WADL file (describing API interface).|
|Destination-based Usage Tracking|
Enable this feature to generate a graph showing the number of times an API accesses its destination addresses. This graph is generated in the API Manager Statistics dashboard. It gives API Publishers an insight about the requests that leave the Gateway to destination endpoints, especially useful in cases where the same API can reach different endpoints (e.g., Load-balanced endpoints).
You can specify the API implementation inline, without connecting to a backend where the API is implemented. Click the Specify Inline check box and you will find the resource created in the design section. For each HTTP method, you can write your own implementation in the Script section. For example,
Deploy as a prototype
If you click the Deploy Prototype button, the API will be deployed as a sample or a model API. The purpose of a prototyped API is to give the API users an early implementation of the API so that they can use it without subscribing, comment on its effectiveness and request improvements. You then change the API's implementation according to user comments and publish it. A published API is available for subscription and monetization.
Go to the API Store (https://localhost:9443/store/) and click the Prototyped APIs menu to see your API deployed there. Then, open the API. For example:
Note that the subscription options are not available for the API. But, users can test the API using the API Console tab, read documentation, engage in forums and other community features and share comments about the API.
Next, start managing the API.