The Richardson maturity model is a model that was developed by Leonard Richardson, and its purpose is to measure the maturity of APIs by providing some general criteria. The model has four classification steps, from Level 0 to Level 3. The highest level corresponds to a more compliant service. This model isn't just for theoretical purposes; it also helps us understand some of the recommended methods for web service development. Let's take a look at an overview of these different levels. The following diagram shows the structure of the levels in the Richardson maturity model:

A generic service is at Level 0: The Swamp of Plain Old XML when it uses a generic protocol superficially (in the case of web services, this is HTTP). An example of this is a heavy SOAP web service. SOAP implementations use only one URI and only one HTTP verb, and they wrap each request message within a massive envelope.

As we mentioned previously, thinking in terms of resources is the best way to understand and design an API. Therefore, a generic service that's at Level 1 uses multiple URIs associated with different resources. For example, if we think about an API of a general store, we could obtain the complete list of product categories by calling this sample URI:

GET https://api.mystore.com/v1/categories 

At the same time, we can get the details of a single category by calling the following URI:

GET https://api.mystore.com/v1/categories/{category_id}

On the other hand, we can get a list of products related to a single category by calling the following URI:

GET https://api.mystore.com/v1/categories/{category_id}/products

As you can see, we can obtain different information by calling different URIs. There is no envelop, and all the requested information is contained in the URI. 

Level 2, which is related to HTTP verbs, introduces the use of HTTP verbs to enhance the information that's transferred on request. Let's take the previous request URI as an example:

https://api.mystore.com/v1/categories/{category_id}/products

This can produce different results, depending on the HTTP verb. The following table shows the meanings of various HTTP verbs:

GET /v1/categories/ HTTP/1.1
Host: api.mystore.com
Content-Type: application/json

POST /v1/categories/ HTTP/1.1
Host: api.mystore.com
Content-Type: application/json

{
 "categoryId": 1,
 "categoryDescription": "Vegetables"
}

PUT /v1/categories/1 HTTP/1.1
Host: api.mystore.com
Content-Type: application/json

{
  "categoryId": 1,
  "categoryDescription": "Fruits and Vegetables"
}

PUT /v1/categories/1 HTTP/1.1
Host: api.mystore.com
Content-Type: application/json

{
  "categoryDescription": "Fruits and Vegetables"
}

DELETE /v1/categories/1 HTTP/1.1
Host: api.mystore.com
Content-Type: application/json

Different HTTP verbs correspond to various data operations. As opposed to a Level 0 service, which doesn't use any specifications of HTTP to deliver information, a Level 2 service takes advantage of HTTP specifications to deliver as much information as possible. Finally, a system with a Level 3 service implements the concept of HATEOAS. As we discussed in the previous section, a HATEOAS provides the resource's URI inside its response. A clear advantage of this approach is that the client doesn't need any information on its side to navigate through the web service's resources. Most importantly, if our web service adds the resource's URI, the client immediately has all the information they need.