WSO2 API Manager has an integrated Swagger UI, which is part of the Swagger project.
Swagger is a 100% open source, standard, language-agnostic specification and a complete framework for describing, producing, consuming, and visualizing RESTful APIs, without the need of a proxy or third-party services. Swagger allows consumers to understand the capabilities of a remote service without accessing its source code and interact with the service with a minimal amount of implementation logic. Swagger helps describe a services in the same way that interfaces describe lower-level programming code.
Also, see the Swagger 2.0 specification.
In this tutorial, let's see how you can add interactive documentation to an API by directly editing the Swagger code and through the API Publisher UI.
This tutorial uses the
PhoneVerification API created in Create and Publish an API.
- Log in to the API Publisher and choose to design a new API.
- In the Design tab, give an API name, a context and a version, and click the Edit Source button under the API Definition section.
The Swagger UI opens. Add the following code under the paths object and click Save. It adds a resource with two HTTP methods into the API.
In the below code, note that you have a resource defined with the URL pattern
pathsobject. This is followed by the HTTP methods GET and POST. For each HTTP method, the following parameters are defined.
- x-auth-type: WSO2-specific object to define the authentication type of the method.
- x-throttling-tier: WSO2-specific object to define the throttling tier of the method.
- responses: An object to hold responses that can be used across operations. See the Swagger specification for details.
- Back in the API Publisher, note that a resource with two HTTP methods are added to the API.
Let's say the backend of this API sends the response in XML format. Let's document this under the GET method in the resource that we just added.
Add the following code under the GET method and click Save.
Back in the API Publisher, note that the response content type has changed to XML.
Tip: You can use this attribute to document the type of the response message that the backend sends. It doesn't do any message type conversion. You can add multiple values as a comma-separated list. E.g.,
produces: "text/xml, application/json"
Add the following code under the GET method and click Save. It adds two parameters to the method.
- Back in the API Publisher, note the two parameters with their descriptions that are added under the GET method.
In the Swagger UI, add the following summary and description to the GET method and click Save.
- Back in the API Publisher, note the summary and description appearing under the GET method.
In the Swagger UI, add the following code under the POST method and click Save. It adds two parameters as
LicenseKeyto pass the payload in. It also changes the datatypes of the parameters to
application/x-www-form-urlencodedas the backend expects that datatype.
Back in the API Publisher, note the parameter that you added are visible under the POST method.
In the Swagger API, change the title of the API as follows. This is the title that is visible to the consumers in the API Console of the API Store, after the API is published.
You will see how this change is reflected in the API Store in the last step of this tutorial.
- Complete the rest of the API creation process. Once you are done, click Save and Publish on the Manage tab to publish the API to the API Store.
- Log in to the API Store and click on the API that you just published.
- The API opens. Go to its API Console tab and note the change that you did earlier now appearing in the API Store for consumers.
In this tutorial, you have seen how the integrated Swagger UI can be used to design, describe and document your API, so that the API consumers get a better understanding of what the API's functionality is.