Introduction to Swagger Documentation FormatIn this section, we look at the generated documentation in detail. Swagger is a specification for documenting REST API. It specifies the format (URL, method, and representation) to describe REST web services. It also provides tools to generate/compute the documentation from the application code. As an application developer, we write web services using a framework, Swagger scans application code, and exposes the documentation on URL. A client can consume this URL and learn how to use REST web services: which HTTP methods to call on which URL, which input documents to send, which status code to expect, etc. We're going to see what is inside the Swagger documentation. When we have a close look at the documentation of the web API, we see some important elements in the starting of the documentation, as shown in the following image. There are following important swagger elements that are present in the Swagger documentation.
We will discuss three elements info, paths, and definitions in detail. Let's see what is inside the info element:
Let's expand the path element. It contains all the path that we are exposing. The two most important resources are "/users" and "/users/{id}". These resources exposes the group of users. Let's expand these two resources one by one. Expanding "/users" resource: The above resource contains the two operations get and post that can be performed. We can use get operation to retrieve all the users and post operation to post a user. Inside the get operation, we get all the response status present there. Response status 200 denotes the successful creation of a user, 401 denotes the unauthorized access of resources, 404 denotes not found, and 403 denotes the forbidden. When we look at the status 200, there is a schema definition. Schema definition shows that we are sending an array of the user as a response. An array of the user is present in the definitions. Similarly, we can also expand the definitions tag to see the definition of the user. In addition to a POST request, we have parameters that send as part of the body of the request. We accept an input type user as the body of the request. Expand "/users/{id}" resource: The /users/{id} resource allows two operations get and delete. Inside the delete method, there is a parameter called id. This id we are accepting in the path while in the post request, we put content as a part of the body of the request. Definition defines different kinds of objects that are being used. These definitions are used in the different operations exposed by each resource. When we perform get operation on /users, it returns a list of users. This resource of the user sending back to get the operation of the resource /user/{id} and the resource of the user contains the additional links. The definition of links is also present in the resource of user type. Links contains a rel and href. A rel is all -users, and href is the link to a particular resource. There are two ways to expose documentation to the client:
|