Now that we have defined our API in RAML and generated the Spring MVC controllers, etc. it is implementation time. Before we write our code, we should consider if we go with a classic 3 tier design or skip some of them.
Last time I wrote the RAML spec for the Kanban API and now we are going to generate some Spring MVC controller for it. So, I setup a Spring Boot project on GitHub and used the Spring MVC - RAML Spec Synchroniser Plugin for Maven.
Now that we have covered the essentials, we could go and hack our MVP together. However, we will look at other options first.
The next thing we should consider in building our API is a versioning scheme. It is inevitable that we are going to change an API and at some point will face backward-incompatible changes. You might ignore it if you only have one client. But trust me, if you don’t consider it from the start, it will ruin your day in the future.
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.