Selecting the appropriate technologies is critical during the inception phase of a project. Most recently, we’ve been adopting a microservices architecture as a solution that satisfies our clients’ needs for modularity and availability.
As a software engineer at Admios, one of our main tasks included the evaluation of frameworks to develop REST API's for one of our clients. The end goal was to reunite all their software services in a single-point access portal.
At the very beginning, selecting the right programming language for the back end was one of the main topics in every analysis of the project. Although Python, Scala and Ruby were considered initially, a backward compatibility with core Java applications was the most important requirement. The evaluation was narrowed down to the available JVM compatible frameworks.
Features of modern REST frameworks in the Java ecosystem:
Although all three options were more than adequate for the task, we decided to use Spring Boot because it relies heavily on the mature Spring Framework, which already contains many useful libraries that make project development easier. Also, there is plenty of documentation on the web for the majority of the topics involved in the framework usage.
Because of the already existing methods, the creation of a REST API in Spring Boot is quite straightforward. In order to demonstrate this, we developed a small application in a CRUD style for the management of our office’s soccer team. For data persistence we used MongoDB and Jongo, the Java driver for queries in Mongo.
The first step was to create a Maven project. We had to add the dependencies for Spring Boot, MongoDB, Jongo and Swagger to document our API. The pom.xml looked like this:
To develop a REST endpoint in Spring Boot, we needed the Main class as a starting point for the application and one or more Models to represent the data objects.
We also needed a controller stereotype for the presentation layer, a service class and a repository for the persistence layer.We used a MongoDB repository in this case, although we could have used any other classic DBMS.
- Controller (or look below)
- Service (or look below)
Finally, we ran the application and we accessed our endpoints from the interface displayed by Swagger at the url: