Implementing APIs

You implement APIs using the following UI in the API Manager. To get to this UI, follow the steps in designing APIs.

You can configure an actual backend or specify the implementation inline. You can also deploy this API as a prototype.

Backend endpoints

An endpoint defines the external destination for an outgoing message.

Field	Description
Endpoint Type	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 endpoint of sandbox (testing) back-end service. A sandbox URL is used for online testing of an API with easy access to an API key. Also see Maintaining Separate Production and Sandbox Gateways. The system reads gateway endpoints from `api-manager.xml` file. When there are multiple gateway environments defined, it picks the gateway endpoint of the production environment. You can define both HTTP and HTTPS gateway endpoints as follows: `<GatewayEndpoint>http://${carbon.local.ip}:${http.nio.port},https://${carbon.local.ip}:${https.nio.port}</GatewayEndpoint>` 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 `Hostname verfiication failed` exception when trying to send requests to a secured endpoint, set `<parameter name="HostnameVerifier">` to `AllowAll` in `<APIM_HOME>/repository/conf/axis2/axis2.xml` file's HTTPS transport sender configuration. For example, `<parameter name="HostnameVerifier">AllowAll</parameter>`. This parameter verifies the hostname of the certificate of a server when API Manager acts as a client and does outbound service calls.
WSDL	URL of WSDL file describing API interface. (E.g., http://ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl) When you provide the WSDL URL, the WSDL content will be saved as a resource file under `/system/governance/apimgt/applicationdata/` `wsdls` folder in the registry. API artifacts have a dependency to this WSDL resource. Its original service address location is reset to the API Gateway's address URL to prevent accessing the service endpoint directly. At the store, we will show the registry permlink of the wsdl resource. User can download the WSDL and create a service project out of that.
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).

Specify Inline

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.