Richardson Maturity Model
   HOME

TheInfoList



OR:

The Richardson Maturity Model (RMM) is a maturity model suggested in 2008 by Leonard Richardson which classifies
Web API A web API is an application programming interface (API) for either a web server or a web browser. As a web development concept, it can be related to a web application's client side (including any web frameworks being used). A server-side web AP ...
s 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. It divides the principal parts of RESTful design into three steps: resource identification (
URI Uri may refer to: Places * Canton of Uri, a canton in Switzerland * Úri, a village and commune in Hungary * Uri, Iran, a village in East Azerbaijan Province * Uri, Jammu and Kashmir, a town in India * Uri (island), off Malakula Island in V ...
), HTTP verbs, and hypermedia controls (e.g.
hyperlinks In computing, a hyperlink, or simply a link, is a digital reference providing direct access to data by a user's clicking or tapping. A hyperlink points to a whole document or to a specific element within a document. Hypertext is text with ...
). 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.


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. Other classification systems for Web API services design also exist, such as CoHA and WS3.


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 Extensible Markup Language (XML) is a markup language and file format for storing, transmitting, and reconstructing data. It defines a set of rules for encoding electronic document, documents in a format that is both human-readable and Machine-r ...
,
JSON JSON (JavaScript Object Notation, pronounced or ) is an open standard file format and electronic data interchange, data interchange format that uses Human-readable medium and data, human-readable text to store and transmit data objects consi ...
, or other text formats. These are typical RPC POX and many
SOAP Soap is a salt (chemistry), salt of a fatty acid (sometimes other carboxylic acids) used for cleaning and lubricating products as well as other applications. In a domestic setting, soaps, specifically "toilet soaps", are surfactants usually u ...
services. Level zero systems don't classify as
RESTful REST (Representational State Transfer) is a software architectural style that was created to describe the design and guide the development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of ...
.


Level 1: Resources

Introduces resources and allows requests for individual
URI Uri may refer to: Places * Canton of Uri, a canton in Switzerland * Úri, a village and commune in Hungary * Uri, Iran, a village in East Azerbaijan Province * Uri, Jammu and Kashmir, a town in India * Uri (island), off Malakula Island in V ...
s (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 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 3: Hypermedia controls

The last level introduces the hypermedia representation. Also called
HATEOAS Hypermedia as the engine of application state (HATEOAS) is a constraint of the REST software architectural style that distinguishes it from other network architectural styles. With HATEOAS, a client interacts with a network application whose appl ...
(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:


References

{{Use dmy dates, date=August 2024 Maturity models