The Richardson Maturity Model (RMM) is a model developed by Leonard Richardson that helps organize your REST APIs into four levels. It is proposed by Leonard Richardson. Here are the four levels of RMM:
Level 0 is also known as POX (Plain Old XML). At this level HTTP is used only as a transport protocol that is used as a remote interaction.
It does not take the advantages of HTTP like different HTTP methods, and HTTP cache. To get and post the data, we send a request to the same URI, and only the POST method may be used.
These APIs use only one URI and one HTTP method called POST. We can say, it exposes SOAP web services in the REST style.
e.g: To get, add, update, delete customer we have only one endpoint http://localhost:8080/customer
Level 1: Resources
At this level, we need to expose different resources (URI's) for API's. Where every URI is the entry point to a specific resource. It exposes resources with proper URI.
At level 1, we break down huge service endpoints into multiple different endpoints. It also uses only one HTTP method POST for retrieving and creating data.
e.g, if we want a list of specific products, we go through the URI http://localhost:8080/products. If we want a specific product, we go through the URI http://localhost:8080/products/mobile.
In Level 1:
-K Himaanshu Shuklaa..
- Level 0: The Swamp of POX
- Level 1: Resources
- Level 2: HTTP Verbs
- Level 3: Hypermedia Control
Level 0 is also known as POX (Plain Old XML). At this level HTTP is used only as a transport protocol that is used as a remote interaction.
It does not take the advantages of HTTP like different HTTP methods, and HTTP cache. To get and post the data, we send a request to the same URI, and only the POST method may be used.
These APIs use only one URI and one HTTP method called POST. We can say, it exposes SOAP web services in the REST style.
e.g: To get, add, update, delete customer we have only one endpoint http://localhost:8080/customer
Level 1: Resources
At this level, we need to expose different resources (URI's) for API's. Where every URI is the entry point to a specific resource. It exposes resources with proper URI.
At level 1, we break down huge service endpoints into multiple different endpoints. It also uses only one HTTP method POST for retrieving and creating data.
e.g, if we want a list of specific products, we go through the URI http://localhost:8080/products. If we want a specific product, we go through the URI http://localhost:8080/products/mobile.
In Level 1:
- Use / to indicate a hierarchical relationship.
- Use , and ; to indicate non-hierarchical relationships.
- Use - and _ to improve the readability.
- Use & to separate parameters.
- Avoid including file extensions.
Level 2: HTTP Verbs
This level indicates that an API must use the protocol properties to deal with scalability and failures.
At level 2, correct HTTP verbs are used with each request and for each of those requests, the correct HTTP response code is provided.
At this level we don't use a single POST method for all requests. We use the GET method when we request a resource, and use the DELETE method when we want to delete a resource. Also, use the response codes of the application protocol.
HTTP verbs and their usage:
- GET retrieves the information.
- POST is used to perform a variety of actions on the server, such as create a new resource, and update an existing resource, or making a mixture of changes to one or more resources.
- DELETE is used to delete a resource.
- PUT is used to update or replace an existing resource or to create a new resource with a URI specified by the client.
- HEAD is used to retrieve the same headers as that of GET response but without any body in the response.
- OPTIONS is used to find the list of HTTP methods supported by any resource or to ping the server.
TRACE is used for debugging, which echo's back headers that it has received.
Out of these Http Verbs, only Post is non idempotent.
Level 3: Hypermedia Controls
This is the highest level and is the combination of level 2 and HATEOAS. It also provides support for HATEOAS(Hypermedia as the Engine of Application State), which is helpful in self-documentation.
This model is heavily used with Microservices Architecture Style once you need to expose your services via on a standardized, easy-to-maintain, and organized API.
What is HATEOAS?
HATEOAS is an acronym for 'Hypertext As The Engine Of Application State'. It means that hypertext should be used to find your way through the API.
HATEOAS implies that the API should guide the client through the application by returning relevant information about the next potential steps (in form of a links), along with each response.
No comments:
Post a Comment