Now that we have settled on using REST, we face the next decision with naming our endpoints. It seems easy, but I’ve found three way so far, and I believe all claim to be best practice. Which I find funny.
We finished with 4 endpoints and the question if we could use REST for the API last time.
What we got so far:
In the center of Kanban is the so-called Kanban Board; yes, it is an actual board. On it, there are usually 3 columns, called swim lanes. The lanes represent the state of a task and are named Ready, Doing and Done; starting on the left. Each individual todo aka task is written on a post-it note and depending on its state, put in a column. Usually, a task will start on the left in Ready.
I published in a recent newsletter how I learn. Today, it’s moving from the secret labs to the open space.
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.