Richardson Maturity Model

Last updated August 09, 2024

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]

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 WS³.^[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"}] }

Related Research Articles

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

WebDAV is a set of extensions to the Hypertext Transfer Protocol (HTTP), which allows user agents to collaboratively author contents directly in an HTTP web server by providing facilities for concurrency control and namespace operations, thus allowing Web to be viewed as a writeable, collaborative medium and not just a read-only medium. WebDAV is defined in RFC 4918 by a working group of the Internet Engineering Task Force (IETF).

Hypermedia, an extension of hypertext, is a nonlinear medium of information that includes graphics, audio, video, plain text and hyperlinks. This designation contrasts with the broader term multimedia, which may include non-interactive linear presentations as well as hypermedia. The term was first used in a 1965 article written by Ted Nelson. Hypermedia is a type of multimedia that features interactive elements, such as hypertext, buttons, or interactive images and videos, allowing users to navigate and engage with content in a non-linear manner.

NetKernel is a British software company and software platform by the same name that is used for High Performance Computing, Enterprise Application Integration, and Energy Efficient Computation.

REST is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hypermedia system, such as the Web, should behave. The REST architectural style emphasises uniform interfaces, independent deployment of components, the scalability of interactions between them, and creating a layered architecture to promote caching to reduce user-perceived latency, enforce security, and encapsulate legacy systems.

A persistent uniform resource locator (PURL) is a uniform resource locator (URL) that is used to redirect to the location of the requested web resource. PURLs redirect HTTP clients using HTTP status codes.

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. A server-side web API consists of one or more publicly exposed endpoints to a defined request–response message system, typically expressed in JSON or XML by means of an HTTP-based web server. A server API (SAPI) is not considered a server-side web API, unless it is publicly accessible by a remote web application.

The HTTP response status code 303 See Other is a way to redirect web applications to a new URI, particularly after a HTTP POST has been performed, since RFC 2616.

In software engineering, a resource-oriented architecture (ROA) is a style of software architecture and programming paradigm for supportive designing and developing software in the form of Internetworking of resources with "RESTful" interfaces. These resources are software components which can be reused for different purposes. ROA design principles and guidelines are used during the phases of software development and system integration.

Web-oriented architecture (WOA) was coined in 2006 by Nick Gall of Gartner. It is a software architecture style that extends service-oriented architecture (SOA) to web-based applications. WOA was originally created by many web applications and sites, such as social websites and personal websites.

Jakarta RESTful Web Services, is a Jakarta EE API specification that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern. JAX-RS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints.

In computing, POST is a request method supported by HTTP used by the World Wide Web. By design, the POST request method requests that a web server accepts the data enclosed in the body of the request message, most likely for storing it. It is often used when uploading a file or when submitting a completed web form.

The HTTP Location header field is returned in responses from an HTTP server under two circumstances:

To ask a web browser to load a different web page. In this circumstance, the Location header should be sent with an HTTP status code of 3xx. It is passed as part of the response by a web server when the requested URI has:
To provide information about the location of a newly created resource. In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202.

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.

In computing, Open Data Protocol (OData) is an open protocol that allows the creation and consumption of queryable and interoperable Web service APIs in a standard way. Microsoft initiated OData in 2007. Versions 1.0, 2.0, and 3.0 are released under the Microsoft Open Specification Promise. Version 4.0 was standardized at OASIS, with a release in March 2014. In April 2015 OASIS submitted OData v4 and OData JSON Format v4 to ISO/IEC JTC 1 for approval as an international standard. In December 2016, ISO/IEC published OData 4.0 Core as ISO/IEC 20802-1:2016 and the OData JSON Format as ISO/IEC 20802-2:2016.

<span class="mw-page-title-main">ColdBox Platform</span> Web application framework

ColdBox is a free, open-source, conventions-based, modular web application framework intended for building enterprise applications with ColdFusion (CFML) using a Hierarchical MVC approach.

Cloud Infrastructure Management Interface (CIMI) is an open standard API specification for managing cloud infrastructure.

RESTful API Modeling Language (RAML) is a YAML-based language for describing static APIs. It provides all the information necessary to describe APIs on the level 2 of the Richardson Maturity Model. Although designed with RESTful APIs in mind, RAML is not capable of describing APIs that obey all constraints of REST. It encourages reuse, enables discovery and pattern-sharing and aims for merit-based emergence of best practices.

Hypertext Application Language (HAL) is a convention for defining hypermedia such as links to external resources within JSON or XML code. It is documented in an Internet Draft, with the latest version 11 published the 10th of October 2023. The standard was initially proposed in June 2012 specifically for use with JSON and has since become available in two variations, JSON and XML. The two associated MIME types are media type: application/hal+xml and media type: application/hal+json.

DICOMweb is a term applied to the family of RESTful DICOM services defined for sending, retrieving and querying for medical images and related information.

References

↑ Richardson, Leonard (20 November 2008). "Justice Will Take Us Millions of Intricate Moves". www.crummy.com. Act Three: The Maturity Heuristic . Retrieved 19 May 2021.{{cite web}}: External link in |location= (help)CS1 maint: location (link)
↑ "Richardson Maturity Model". martinfowler.com. Retrieved 10 December 2020.
1 2 Ivan Salvadori, Frank Siqueira (June 2015). "A Maturity Model for Semantic RESTful Web APIs". Researchgate.net. Retrieved 10 December 2020.
↑ Hiranya Jayathilaka, Chandra Krintz, and Rich Wolski. "Service-driven Computing with APIs: Challenges and Emerging Trends" (PDF). Univ. of California at Santa Barbara, US. Retrieved 11 December 2020.{{cite news}}: CS1 maint: multiple names: authors list (link)
↑ 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 page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] Richardson, Leonard (20 November 2008). "Justice Will Take Us Millions of Intricate Moves". www.crummy.com. Act Three: The Maturity Heuristic . Retrieved 19 May 2021.{{cite web}}: External link in |location= (help)CS1 maint: location (link)

[2] "Richardson Maturity Model". martinfowler.com. Retrieved 10 December 2020.

[:0-3] 1 2 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, US. 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)

[1]

[2]

[3]

[4]

[5]