Editing REST (section)

== Architectural constraints ==
The REST architectural style defines six guiding constraints.<ref name="SOA with REST">{{cite book |last1=Erl |first1=Thomas |last2=Carlyle |first2=Benjamin |last3=Pautasso |first3=Cesare |last4=Balasubramanian |first4=Raj |date=2012 |chapter=5.1 |title=SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST |location=Upper Saddle River, New Jersey |publisher=Prentice Hall |isbn=978-0-13-701251-0 }}</ref><ref name="Richardson 2007">{{cite book |last1=Richardson |first1=Leonard |url=https://archive.org/details/restfulwebservic00rich_0 |title=RESTful Web Services |last2=Ruby |first2=Sam |date=2007 |publisher=O'Reilly Media |isbn=978-0-596-52926-0 |location=Sebastopol, California |language=en-US |url-access=registration}}</ref> When these constraints are applied to the system architecture, it gains desirable [[non-functional requirement|non-functional properties]], such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability.<ref name="Fielding-Ch5"/>

The formal REST constraints are as follows:<ref>{{Cite web |title=What is REST API? |url=https://www.visual-paradigm.com/guide/development/what-is-rest-api/ |access-date=2024-02-24 |website=www.visual-paradigm.com |archive-date=2024-02-24 |archive-url=https://web.archive.org/web/20240224173920/https://www.visual-paradigm.com/guide/development/what-is-rest-api/ |url-status=live }}</ref>

* Client/Server – Clients are separated from servers by a well-defined interface
* Stateless – A specific client does not consume server storage when the client is "at rest"
* Cache – Responses indicate their own cacheability
* Uniform interface
* Layered system – A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way
* Code on demand (optional) – Servers are able to temporarily extend or customize the functionality of a client by transferring logic to the client that can be executed within a standard virtual machine

=== Uniform interface ===
The uniform interface constraint is fundamental to the design of any RESTful system.<ref name="Fielding-Ch5"/> It simplifies and decouples the architecture, which enables each part to evolve independently. The four constraints for this uniform interface are:

* Resource identification in requests: Individual resources are identified in requests using [[uniform resource identifier|URIs]]. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server could send data from its database as [[HTML]], [[XML]] or as [[JSON]]—none of which are the server's internal representation.
* Resource manipulation through representations: When a client holds a representation of a resource, including any [[metadata]] attached, it has enough information to modify or delete the resource's state.
* Self-descriptive messages: Each message includes enough information to describe how to process the message. For example, which parser to invoke can be specified by a [[media type]].<ref name="Fielding-Ch5" />
* Hypermedia as the engine of application state ([[HATEOAS]]) – Having accessed an initial URI for the REST application—analogous to a human Web user accessing the [[home page]] of a website—a REST client should then be able to use server-provided links dynamically to discover all the available resources it needs. As access proceeds, the server responds with text that includes [[hyperlink]]s to other resources that are currently available. There is no need for the client to be hard-coded with information regarding the structure of the server.<ref name="RESTfulAPI.net">{{cite web |last=Gupta |first=Lokesh |date=2 June 2018 |title=REST HATEOAS |url=http://restfulapi.net/hateoas/ |url-status=live |access-date=March 10, 2019 |website=REST API Tutorial |publisher=RESTfulAPI.net |language=en-US |archive-date=7 April 2019 |archive-url=https://web.archive.org/web/20190407073345/https://restfulapi.net/hateoas/ }}</ref>