Swagger API endpoints

The microservice architecture relies heavily on API calls between the gateway and services, services and the registry, and the gateway and registries. Therefore, it is essential for developers and users to get to know the API endpoints that they can access, as well as the information that's required to access those endpoints. 

This can be a lot of work. Fortunately, libraries such as Swagger come to the rescue. We just have to add the standard comments to the methods; then, the Swagger API will do the necessary work to extract information from them and convert them into a beautiful user interface:

The preceding screenshot shows the default generated Swagger UI page. It lists all the endpoints that are available and then supplies the list of operations that it provides. It shows the playground where we can frame requests and test them for output.

Normally, the Swagger API docs are only available in development mode. If you are developing an API service and if there is a need to expose this to end users or external developers using your service, you can enable it in production by setting the swagger profile, along with the prod profile, by setting the spring.profiles.active=prod,swagger property in the application-prod.yaml file.

Similar to the other pages, this also lists the various instances that are connected to this registry service. We can select them from the drop-down menu (upper-right corner) to see what APIs are provided by various applications:

The operations listed in the gateway API will provide the following information:

This lists all the operations that are available in the AccountResource file. It shows the method type (GET/POST/PUT/DELETE), as well as the endpoint and the method name that is present in the AccountResource file:

Upon clicking any one of the endpoints that's available, you will see detailed information about the response classes, response errors, response content type, as well as how the response object is structured. In addition to this, it also shows how the model object is constructed. These are particularly helpful for end users who want to access these APIs:

UserDTO {
activated (boolean, optional),
authorities (Array[string], optional),
createdBy (string, optional),
createdDate (string, optional),
email (string, optional),
firstName (string, optional),
id (integer, optional),
imageUrl (string, optional),
langKey (string, optional),
lastModifiedDate (string, optional),
lastModifiedBy (string optional),
lastName (string, optional),
login (string)
}

Next, there is the option to try out the endpoint by clicking the Try it out button:

This shows the request and its response. It also shows how to frame the request, along with the authentication token:

Also, it provides the response code and the response header information that is returned by the server, which is also extremely useful for API programmers.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset