Representational State Transfer (REST) APIs exchange the representations of a resource in different formats (for example, JSON, XML, and others) between a server and client, using the existing mechanisms of the web, such as HTTP protocols, verbs, and response codes. The same APIs can be used as the backend for different apps (for example, web, mobile, and so on), based on different UI technologies (for example, Angular and React). Traditional MVC applications use a server-side view technology (such as JSP, ASP.net, PHP, and so on) that is tied to the backend code, and changing UI requires changing backend.

REST defines six architectural constraints, namely uniform interface, client-server, stateless, cacheable, layered system, and code on demand (optional). The uniform interface and client-server constraints are achieved by using the HTTP protocol, verbs, response codes, and so on. The client should take care of maintaining the state, and not the server (this is known as statelessness), which leads to cacheable URIs. APIs can be implemented in various layers, without letting the client know. Optionally, the server can respond with client-executable code on demand (code).

Richardson's Maturity Model can be used to check the level of RESTfulness. If we only use HTTP for transport, then the level is 0 (as in traditional SOAP services that use RPC over HTTP). Level 1 requires using URIs based on resources (for example, student/1). Level 2 requires using HTTP verbs to denote the operations (for example, DELETE to delete a resource). Level 3 requires using hypermedia as the engine of application state (HATEOAS), by providing links in responses (for example, URIs, for supported operations) to drive the application's state transitions.