Last Update: 24.11.2017. By Jens in APIs
When building APIs in Java, we have some more options than just Spring Boot. No, I am not talking about JEE. We actually have some more options.
This is the fourth part of the API documentation series. In the last part we explored RAML as a solution, and in this article, we are covering OpenAPI.
This is the third part of the API documentation series. In the last part we explored the first solution using API Blueprint a bit, and in this article, we are covering RAML.
This is the second part of the API documentation series. In the first, we covered for whom the documentation is written, what it should contain and the three different types of writing it. Starting with this part, we dive a bit deeper into the latter and explore some standard formats and ways of writing.
Documenting your API is extremely important. Without documentation, nobody, not your product owner, devs or your customers know what your API does and how to use it. In this article series, we will take a look at common ways of documenting, their advantages and disadvantages and explore different solutions.
APIs have gone a long way from a purely technical thing to now being a core business. Many businesses depend so much on their APIs that they would go out of business when the APIs fail. But whos responsible for building and maintaining?
Or when is a REST API a REST API? That is the question. And there is no easy answer. Let’s take a closer look.
In your Spring MVC application, you will usually have at least one endpoint which accepts and ID as a path variable or request parameter, and often the next thing you will do is to load the model from your Spring Data repository. However, there is an easier way as you will see in a minute.
In this tutorial, I show you an easy way for handling pagination when you use Spring Data and Spring MVC in your application you might not be aware of.