In the article, I talk about monolithic, SOA, microservices, and serverless approaches. I focus on microservices with the best practices on using HTTP codes in the API REST.
First of all, let’s compare the monolithic approach, SOA and microservices from the point of view of their main characteristics: granularity and coupling. I will help you to understand the evolution of theses approaches and their advantages and weaknesses.
With the monolithic approach, there is only one software unit, including all the features. It’s the traditional approach. It’s exactly the opposite to microservices.
SOA (Service Oriented Architectures) follows a distributed systems approach whose main characteristics are:
- services are weakly coupled,
- the interface and protocol are standard,
- Multi-platform integration is seamless.
Communication is done via an ESB (Enterprise Service Bus).
A service has four properties:
- It represents a commercial activity with a precise outcome.
- It is autonomous.
- It is a black box for its consumers.
- It can rely on other services.
The principles of SOA :
- Standardized service contract,
- Autonomy of services,
- Discovery of services,
- Reuse of services,
- Encapsulation of services.
The SOA Manifesto :
- Business value is given more importance than technical strategy
- Strategic goals are given more importance than project-specific benefits
- Intrinsic inter-operability is given more importance than custom integration
- Shared services are given more importance than specific-purpose implementations
- Flexibility is given more importance than optimization
- Evolutionary refinement is given more importance than pursuit of initial perfection
Microservices are the splitting of an application into small, loosely coupled services. They are the opposite of a monolithic architecture.
Microservices are :
- weakly coupled,
- with small granularity.
They use lightweight protocols.
Microservices are independent:
- independent code bases,
- independent process execution,
- independent build,
- independent deployment,
- independent scaling.
The advantages of microservices are :
Microservices are especially very well adapted to Agile and DevOps mindsets:
- small size of autonomous teams,
- continuous refactoring,
- using a CI/CD.
Serverless is an available service on Clouds (for example: Function Compute on Alibaba Cloud, Lambda Function for AWS, Azure Serverless on Azure, Cloud Functions for Google, Qinling for Open Stack).
The advantages of Serverless are:
- pay-as-you-go service,
- no cost for infrastructure management,
- stateless by design,
- support event handlers and scheduled jobs.
Now let’s focus on microservices and let’s introduce the best practices for API RESTs.
REST (REpresentational State Transfer) is a stateless communication between a client and a server based on their separation.
The workflow is as follows.
The first step - A client sends a request to the server, including the following items:
- the HTTP verb,
- the headers indicate the type of content that can be received :
Acceptfollowed by the MIME type in the format
- the resource path must be plural, except when accessing a single resource (example :
- the message body (optional).
The main HTTP verbs, related to CRUD, are:
GET: reads the data and doesn't change the application state,
POST: creates resources and requests on data by using conditions,
PUT: updates resources,
DELETE: deletes resources from a database.
The second step - The server sends the response to the client, including the following items:
- the content type,
- the response code.
The main response codes are:
200 (OK): request accepted,
201 (Created): resource created,
202 (Accepted): request accepted but not completed,
204 (No Content): successful request (empty response body),
400 (Bad Request): request not understood by the server (malformed syntax),
401 (Unauthorized): missing authentication header or invalid credentials,
403 (Forbidden): no permission for the client to access the resource,
404 (Not Found): resource not found,
405 (Method Not Allowed): requested operation not supported on the specified artifact type,
409 (Conflict): attempt to update an object while it is undergoing an asynchronous operation,
500 (Internal Server Error): triggers an exception on the server.
There is something special about the codes
2xx : the response code depends on the verb and embeds semantics:
GET: 200 (OK),
POST: 201 (CREATED),
PUT: 200 (OK),
DELETE: 204 (NO CONTENT).
Now, you should identify clearly when the approach is monolithic, SOA, microservices or serverless. And, more important, you have the basis to implement correctly API REST. These rules are very important.