Introducción

The REST architectural style

Representational state transfer (REST) is an abstraction of the architecture of the World Wide Web;

REST is an architectural style consisting of a coordinated set of architectural constraints applied to

• components,
• connectors, and
• data elements,

within a distributed hypermedia system.

The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation at UC Irvine.

The REST architectural style is often applied to the development of web services as an alternative to other distributed-computing specifications such as SOAP (Simple Object Access protocol).

Web Services

A Web Service is a method of communication between two electronic devices over a network.

It is a software function provided at a network address over the web with the service always on as in the concept of utility computing^54.1.

The W3C defines a Web service generally as:

A software system designed to support interoperable machine-to-machine interaction over a network.

RESTful Web Services

One can characterize web services as RESTful if they conform to the constraints described in the architectural constraints.

Web service APIs that adhere to the architectural constraints are called RESTful.

HTTP based RESTful APIs are defined with these aspects:

1. base URI, such as http://example.com/resources/
2. an Internet media type for the data. This is often JSON^54.2 but can be any other valid Internet media type (e.g. XML, Atom^54.3, microformats^54.4, etc.)
3. standard HTTP methods (e.g., GET, PUT, POST, or DELETE)
4. hypertext links to reference state
5. hypertext links to reference related resources

The following table shows the HTTP methods that are typically used to implement a RESTful API.

RESTful API HTTP methods
Resource	GET	PUT	POST	DELETE
Collection URI, such as http://example.com/resources	List the URIs and perhaps other details of the collection's members.	Replace the entire collection with another collection.	Create a new entry in the collection. The new entry's URI is assigned automatically and is usually returned by the operation.	Delete the entire collection.
Element URI, such as http://example.com/resources/item17	Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.	Replace the addressed member of the collection, or if it doesn't exist, create it.	Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it.	Delete the addressed member of the collection.

Safe and Idempotent Methods

• The PUT and DELETE methods are referred to as idempotent, meaning that the operation will produce the same result no matter how many times it is repeated.
• The GET method is a safe method (or nullipotent), meaning that calling it produces no side-effects. In other words, retrieving or accessing a record doesn't change it.
• The POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful.

  While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may re-submit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.

• Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other non-idempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences, if a user agent assumes that repeating the same request is safe when it isn't.
• Safe and Idempotent Methods part of Hypertext Transfer Protocol - HTTP/1.1 RFC 2616 Fielding, et al.

Unlike SOAP-based web services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, unlike SOAP, which is a protocol.