Richardson Maturity Model

The Richardson Maturity Model (RMM) is a maturity model suggested in 2008 by Leonard Richardson which classifies Web APIs based on their adherence and conformity to each of the model's four levels. The aim of the research of the model as stated by the author was to find out the relationship between the constraints of REST and other forms of web services.[1]

It divides the principle parts of RESTful design into three steps: resource identification (URI), HTTP verbs, and hypermedia controls (e.g. hyperlinks).[2]

The RMM has been cited useful in evaluating the quality of particularly RESTful Web API design (even though it is not restricted to REST alone) and criticized for not addressing how a system could achieve the highest maturity levels of the model as well as for considering a limited number of quality attributes.[3]

Overview

The RMM can be employed to determine how well a Web service architecture adheres to REST principles. It categorizes a Web API into four levels (from 0 to 3) with each higher level corresponding to a more complete adherence to REST design. The next level also contains all the characteristics of the previous one.[4][5]

Other classification systems for Web API services design also exist, such as CoHA and WS3.[3]

Levels

Level 0: The Swamp of POX

The lowest level of the model describes a Web API with a single URI (typically POST over HTTP) accepting all the range of operations supported by the service. Resources in this form cannot be well-defined. Messaging is done in XML, JSON, or other text formats. These are typical RPC POX and many SOAP services.

Level Zero systems don't classify as RESTful.

Level 0 API Examples
URI HTTP Verb Operations
/bookingService POST retrieve destinations/hotels/rooms; add/cancel a reservation; etc.
/newsFeedService POST get all news; get all news in category specified; get all news of an outlet specified; etc.

Level 1: Resources

Introduces resources and allows requests for individual URIs (still all typically POST) for separate actions instead of exposing one universal endpoint (API). The API resources are still generalized but it is possible to identify the scope of each one.

Level One design is not RESTful, yet it is organizing the API in the direction of becoming one.

Level 1 API Examples
URI HTTP Verb Operation
/bookingDestinations POST retrieve destinations
/bookingReservations POST add/cancel reservations
/bookingRooms POST add/cancel special requests to a reservation
/bookingFeedback POST leave feedback

Level 2: HTTP verbs

The system starts making use of HTTP Verbs. This allows for further specialization of the resource and thus narrows down the functionality of each individual operation within the service. The principal separation at this level consists in splitting a given resource into two – one request for obtaining data only (GET), the other for modifying the data (POST). Further granularization is also possible. GET requests only fetch data, POST/PUT calls introduce new and update existing data, and DELETE requests remove or otherwise invalidate previous actions. One drawback of providing a distributed service with more than GET and POST verbs per resource might be growing complexity of using such a system.

Level 2 API Examples
URI HTTP Verb Operation
/destinations GET retrieve destinations
/reservations GET get reservations according to certain criteria
/reservations POST add/cancel reservations
/rooms POST request room extras
/rooms DELETE remove room extras

Level 3: Hypermedia controls

The last level introduces the hypermedia representation. Also called HATEOAS (Hypermedia As The Engine of Application State), these are elements embedded in the response messages of resources which can establish a relation between individual data entities returned from and passed to the APIs. For instance, a GET request to a hotel reservation system might return a number of available rooms along with hypermedia links (these would be html hyperlink controls in the early days of the model) allowing the client to book specific rooms.

This is the last level of the Richardson Maturity Model.

Request:

GET /room/?customerId=1&date=10-11-2020&hotelCode=ASTORIA HTTP/1.1

Response:

{   
   customerId: "1",
   reservations: [{room: "102", checkin: "10-11-2020", checkout: "11-14-2020", price: "100", href: "https://localhost:8080/room/102"}]
}

References
  1. Richardson, Leonard (2008-11-20). "Justice Will Take Us Millions of Intricate Moves". www.crummy.com. Act Three: The Maturity Heuristic. Retrieved 2021-05-19. {{cite web}}: External link in |location= (help)CS1 maint: location (link)
  2. "Richardson Maturity Model". martinfowler.com. Retrieved 2020-12-10.
  3. Ivan Salvadori, Frank Siqueira (June 2015). "A Maturity Model for Semantic RESTful Web APIs". Researchgate.net. Retrieved 10 December 2020.
  4. Hiranya Jayathilaka, Chandra Krintz, and Rich Wolski. "Service-driven Computing with APIs: Challenges and Emerging Trends" (PDF). Univ. of California at Santa Barbara, USA. Retrieved 11 December 2020.{{cite news}}: CS1 maint: multiple names: authors list (link)
  5. Arne Koschel, Irina Astrova,Maximilian Blankschyn, Dominik Schöner, and Kevin Schulze. "Evaluating the RESTfulness of "APIs from the Rough"" (PDF). Proceedings of the 15th International Conference on Web Information Systems and Technologies (WEBIST 2019). Retrieved 11 December 2020.{{cite news}}: CS1 maint: multiple names: authors list (link)
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.