When we return error messages, and along, we should not expose too much information. Same goes for normal data. More, especially detailed is not always better. It depends on the type of API and what the clients do with it and who the clients are.
Last time we talked about using proper HTTP status codes and also returning errors in a JSON format back to the client.
Let’s start talking about error handling in our API.
The black box testing with a RAML tool failed last time, so we are left with unit and our own integration tests. Which brings me to the point what should we use? Should our tests focus more on pure unit testing or more integration tests, testing different parts at the same time?
This episode is another one of “it didn’t work out as planned.” I originally wanted to use Abao as a tool for testing my API implementation against the RAML description. Unfortunately, Abao only works with RAMl 0.8 and not with RAML 1.0 which I was using. The request ticket for RAML 1.0 support was opened in 2015 and is still not done.
I implemented a basic version of the TaskService today. You can find the full version in the GitHub repo as I’ll only discuss certain findings.
Now that we have settled with a DB, it is time to define our model.
Today, we are going to decide which data storage we will use. A few years ago, it was pretty clear to go with an RDBMS, but nowadays we have a few other options we can consider. If we have a choice at all. In the enterprise world, we are often restricted by some company policies or standards.
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.