Richardson Maturity Model

Last updated

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]

Contents

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
URIHTTP VerbOperations
/bookingServicePOSTretrieve destinations/hotels/rooms; add/cancel a reservation; etc.
/newsFeedServicePOSTget 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
URIHTTP VerbOperation
/bookingDestinationsPOSTretrieve destinations
/bookingReservationsPOSTadd/cancel reservations
/bookingRoomsPOSTadd/cancel special requests to a reservation
/bookingFeedbackPOSTleave 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
URIHTTP VerbOperation
/destinationsGETretrieve destinations
/reservationsGETget reservations according to certain criteria
/reservationsPOSTadd/cancel reservations
/roomsPOSTrequest room extras
/roomsDELETEremove 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

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (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.

Hypermedia, an extension of the term 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. It is also related to the field of electronic literature. The term was first used in a 1965 article written by Ted Nelson.

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 an Internet-scale distributed hypermedia system, such as the Web, should behave. The REST architectural style emphasises the scalability of interactions between components, uniform interfaces, independent deployment of components, and the creation of a layered architecture to facilitate caching of components 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.

<span class="mw-page-title-main">Web API</span> HTTP-based application programming interface used in web development

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.

<span class="mw-page-title-main">HTTP 303</span> HTTP response status code

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.

<span class="mw-page-title-main">POST (HTTP)</span> Request method in the HTTP protocol

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 accept 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.

<span class="mw-page-title-main">HTTP location</span> Instruction by web server containing the intended location of a web page.

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

  1. 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:
  2. 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 application architecture that distinguishes it from other network application architectures.

In computing, Open Data Protocol (OData) is an open protocol that allows the creation and consumption of queryable and interoperable REST 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, however, the latest version of HAL Internet-Draft expired on November 12, 2016. 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.

Gemini is an application-layer internet communication protocol for accessing remote documents, similar to the Hypertext Transfer Protocol (HTTP) and Gopher. It comes with a special document format, commonly referred to as "gemtext", which allows linking to other documents. Started by a pseudonymous person known as Solderpunk, the protocol is being finalized collaboratively and as of October 2022, has not been submitted to the IETF organization for standardization.

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. 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, 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 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.