Richardson Maturity Model

The Richardson Maturity Model is a framework for evaluating the maturity of web services in terms of their adherence to RESTful principles.

In the world of web services and API design, achieving a high level of maturity and compliance with RESTful principles is often a goal for many developers and architects. The Richardson Maturity Model (conceived by Leonard Richardson) provides a structured way to measure the maturity and adherence of web services to REST principles.

Let’s delve into the Richardson Maturity Model and explore the significance of each maturity level.

1. What is the Richardson Maturity Model?

The Richardson Maturity Model is a framework for evaluating the maturity of web services in terms of their adherence to RESTful principles. Leonard Richardson analyzed a hundred different web service designs and divided these designs into four categories. These categories are based on how much the web services are REST compliant.

Richardson used three main factors to decide the maturity of a service. These factors are:

  1. URI
  2. HTTP Methods,
  3. HATEOAS (Hypermedia)

The more a service leverages these factors, the higher its maturity level.

2. Maturity Levels

In his analysis, Richardson described a total of 4 maturity levels as given below. Note that Roy Fielding, one of the co-authors of the HTTP specification and a key figure in REST architecture, has already made it very clear that level 3 RMM is a pre-condition of REST.

2.1. Level Zero

Level Zero represents the most basic form of building service-oriented applications.

Level zero of maturity does not make use of any of URI, HTTP Methods, and HATEOAS capabilities.

The services at zero maturity level have a single URI and use a single HTTP method (typically POST).

For example, most SOAP Web Services use a single URI to identify an endpoint, and HTTP POST to transfer SOAP-based payloads, effectively ignoring the rest of the HTTP verbs.

Similarly, XML-RPC-based services send data as Plain Old XML (POX).

These are the most primitive ways of building SOA applications with a single POST method endpoint and using XML to communicate between the client and the server.

2.2. Level One

Level One introduces the use of URIs for resource identification.

Level one of maturity makes use of URIs, but does not use the HTTP Methods, and HATEOAS.

At this level, services offer multiple URIs to represent various resources within the system, but they typically use a single HTTP verb, often POST, for interactions. Each resource is identified by a unique URI, enhancing the design compared to Level Zero.

However, the absence of multiple HTTP methods and HATEOAS capabilities means that the services do not fully embrace RESTful principles.

2.3. Level Two

Level Two marks a significant advancement in RESTful maturity.

Level two of maturity makes use of URIs and HTTP Methods, but does not use the HATEOAS.

The level two services generally host numerous URIs i.e. addressable resources. Such services support several of the HTTP verbs on each exposed resource – Create, Read, Update, and Delete (CRUD) services. Here the state of resources, typically representing business entities, can be manipulated over the network.

The designers of the level two services expect people to put some effort into mastering the APIs – generally by reading the supplied documentation.

Maturity level 2 is the most popular usecase of REST principles, which advocate using different verbs based on the HTTP request methods, while the system can have multiple resources.

2.4. Level Three

Level Three represents the pinnacle of RESTful maturity according to the Richardson Maturity Model. Services at this level fully embrace all three key aspects: URIs, HTTP methods, and HATEOAS.

Level three of maturity makes use of all three, i.e. URIs and HTTP, and HATEOAS.

At level three, services prioritize easy discoverability and self-descriptiveness. This level makes it easy for the responses to be self-descriptive by using HATEOAS. By utilizing HATEOAS, clients can navigate and understand the service without relying extensively on external documentation.

Level three services lead the service consumers through a trail of resources, causing application state transitions as a result.

4. Summary

Richardson Maturity Model serves as a reference for assessing and improving the design of RESTful web services. It highlights the importance of URI design, HTTP methods, and HATEOAS in achieving different levels of RESTful maturity. By understanding and applying these principles, developers, and architects can create REST web services that are not only well-structured but also highly efficient and accessible.

References:

Act Three: The Maturity Heuristic

Comments

Subscribe
Notify of
guest
6 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Leo Jones

is it worth trying to reach Level 3 according to the Richardson maturity model? Please describe a case when it could be beneficial.

Marcjae Persigas

How to make a maturity assessment on the existing API at your own disposal?

PranDev

Thank you so much, really great explanation.
How can I ensure the level three REST? Could you please provide reference of any real time example which uses HATEOAS?

Phyo Kyaw San

Hi, thank for the author for explaining the Maturity Model. I am wondering that if I developed an API that is capable, say, to the level 2 of the Maturity Model, can that still be called RESTful API. Thanks.