Designing a REST API — What Is a Code-First Approach?
In this article, we continue to see how to design a REST API and look at the Code-First approach.
Join the DZone community and get the full member experience.Join For Free
Designing a great REST API is important to have great microservices. The Code-First approach focuses on generating the contract from code. Is it the best possible approach?
You might also like: Code-First Approach With ASP.NET MVC Framework
You Will Learn
- What is the Code-First approach to designing a REST API?
- What are advantages of the Code-First approach?
- What are disadvantages of the Code-First approach?
- When do you adopt the Code-First approach?
This is the fourth article in a series of articles on REST APIs:
- 1 - Introduction to REST APIs — RESTful Web Services
- 2 - REST vs SOAP — A Few Perspectives
- 3 - Designing a REST API — What Is Contract First?
What Is Code First?
Whenever you develop a service, such as a REST API or a SOAP API, there are two approaches you could choose from:
- Code First, and generate the contract out of the code
- Contract First, and develop the code based on the contract
Let's start with a quick example for Code First.
Spring Boot Code First REST API Example
We are developing a RESTful web service by making use of the Spring Boot Framework to generate the API. For example, in the
retrieveAllUsers() API, we expose the
"/users" URI and return all the user resources by calling a service method. when we hit this URL, we get these users returned:
In a similar manner, there are other service methods defined, each with their own URI. What we are doing with this example is taking the code and generating documentation from it. That documentation lists out how a user can use the service. For this, we use a documentation format called Swagger:
Swagger enables us to generate documentation from the code. For example, the following is what Swagger generates for a request to retrieve all users:
It lists out the kind of response message we get and the response status accompanying it as well. You can even call that service from Swagger, leading to:
You can also send a POST request to
Swagger tells us how to structure the request message and specify the individual field formats inside. It will also tell you the type of response you get back, along with the response code.
What Swagger generates out of the code is called a contract.
Advantages of Code First
The advantages of this approach are mainly:
- Low-effort contracts: Generating the contract does not require any additional effort. It is just a by-product of the service development, as it can be automatically generated from the code
- Contract, code in-sync: As the contract is generated from the code, the two always in sync with each other
Disadvantages of Code First
The disadvantages of this approach are as follows:
No Parallel Development
The service producer and the service consumers cannot be developed in parallel. First, the service needs to be developed, then the contract is generated, and only after that, consumer code can be written to adhere to the contract. Without understanding the contract, a consumer cannot be developed.
No Target for Teams
As the contract cannot be known before the service is developed, there is no target for the various stakeholders in development. Hence, there is every chance that directions go wayward, and unnecessary changes are made, leading to wastage of effort.
No Cross-Platform Compatibility
In some older frameworks, it is not that easy to generate the contract from the code. As a result, it is quite common for the contracts generated not being compatible across platforms.
Check out our video on this:
In this article, we explored the code-first approach of building a REST API. While the code-first approach is efficient from a developer's perspective, it has significant challenges when it comes to developing the service provider and consumer together.
Published at DZone with permission of Ranga Karanam, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.