Maturity Levels
Not every API is also a REST API. Until an API really becomes a REST API - Martin Fowler has called this the “Glory of REST” or also “Steps towards REST” - different levels have to be reached. The levels (Level 0 to Level 3) originate from Leonard Richardson, who divided the respective principles into the four levels known today.
It should be said that very few APIs actually fully achieve the rules of all four levels. Especially the last level - Hypermedia - is reached by almost no API. Very rare to see this.
Level 2 is considered the most common designation of REST today.
Why those levels?
In principle, you would not need these levels. However, they help enormously in both the architecture and implementation phases to ensure that recognizable mechanisms are used, thus creating a common basis for both tooling and developers.
Even if other APIs may not follow these levels, it makes sense for your API.
Your users will thank you for it.
Level 0 - Thanks for interfacing at all
Level 0 is still very common today, if not the most common level at all.
This level does not describe anything other than communication: HTTP is used as the basic channel. No more, and no less.
Especially for very simple APIs in the professional environment, APIs are implemented in the so-called RPC style: there is one flat URL per action, like /task/createTask
, /task/deleteTaskById
.
This is not a bad thing across the board: alternatives to REST (like gRPC) still follow this style today and there are valid use cases for it. But this is not a REST API.
Level 1 - Urls and Resources
Resources, or entities, are the basic building block of any REST API. Level 1 describes how URLs and the various resources are handled in an API or in an application. Thereby each resource gets its own endpoint.
Resource | Endpoint |
---|---|
Users | /users |
Tasks | /tasks |
Producs | /products |
However, this does not only apply to the endpoints of an entire collection, but also to the respective resource, for example /users/ben
. If a resource also has sub-resources, i.e. a nested structure, level 1 also describes the access to this resource through the URL structure. For the following example the responsible person of a task is reachable via /task/123/assginee
{
"id" : 123,
"title": "This is the task title",
"assignee" : {
"id": 315,
"name: "Batman"
}
}
Level 2 - This is REST today
Method | Description |
---|---|
GET | GET is used to retrive an entity or a collection of entities of an endpoint (URI). |
POST | POST is used to pass an entity to an endpoint (URI). It is used to create an entity or modify a state. |
PUT | PUT also passes an entity to an endpoint, but ensures that an existing entity on the server is completely overwritten. |
PATCH | PATCH is the possibility to change an existing resource on the server only partially. |
DELETE | DELETE deletes an existing entity on the server |