Beruflich Dokumente
Kultur Dokumente
Understanding REST
What is REST?
REST is an architectural style for distributed systems. An architectural style is:
a coordinated set of architectural constraints that restricts the roles/features of elements and the allowed relationships among those elements within any architecture that conforms to that style.
or
an abstraction, a design pattern, a way of discussing an architecture without concern for its implementation.
Spring 2010
mark.baker@computer.org
Understanding REST
What is REST?
REST defines a series of constraints for distributed systems that together achieve the properties of:
Simplicity, Scalability, modifiable, performance, visibility (to monitoring), portability and reliability.
A system that exhibits all defined constraints is RESTful! Systems may add additional constraints or relax existing constraints, in which case they are more or less RESTful:
REST is not a set of laws or even a specification it is a style
Spring 2010 mark.baker@computer.org
Understanding REST
Representational State Transfer:
The Resource:
A resource is any information that can be named: documents, images, services, people, an collections.
Spring 2010
mark.baker@computer.org
Understanding REST
Representational State Transfer:
On request, a resource may transfer a representation of its state to a client:
Necessitates a client-server architecture.
Representations returned from the server should link to additional application state:
Clients may follow a proposed link and assume a new state Hypermedia as the engine of application state.
Spring 2010
mark.baker@computer.org
Understanding REST
Representational State Transfer:
Stateless interactions:
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
Spring 2010
mark.baker@computer.org
Understanding REST
What is REST:
REST is a coordinated set of architectural constraints that attempts to minimise latency and network communication while at the same time maximizing the independence and scalability of component implementations. . REST enables the caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meeting the needs of an Internet-scale distributed hypermedia system (Roy Fielding), Principal author of the HTTP 1.0, HTTP 1.1, and URI spec. Co-founder of The Apache Software Foundation.
Spring 2010 mark.baker@computer.org
HTTP 1.1
URIs: RFC 3986
Spring 2010 mark.baker@computer.org
Spring 2010
mark.baker@computer.org
A request is sent to a specified URI (addressabilty), An HTTP request/response is an envelope, Inside the envelope are headers followed by a resource representationif any (self-descriptive).
Spring 2010
mark.baker@computer.org
Spring 2010
mark.baker@computer.org
Spring 2010
mark.baker@computer.org
Spring 2010
mark.baker@computer.org
Schema languages are not required (if even possible). Representations should be well-known media types (MIME types). Try and use up-stack media types:
Makes your resources maximally accessible, XHTML or Atom instead of vanilla XML.
Spring 2010
mark.baker@computer.org
Spring 2010
mark.baker@computer.org
GET is idempotent:
Multiple requests are the same as a single request, Might be impacted by concurrent operations.
Spring 2010
mark.baker@computer.org
Spring 2010
mark.baker@computer.org
Spring 2010
mark.baker@computer.org
Spring 2010
mark.baker@computer.org
The possible states of a server are also resources, and have URIs:
The 10th through Xth pending expense reports
/expenses;pending,start=10
Can be retrieved without first visiting the first page of expenses, No synchronized state needed, e.g. FTPs working directory.
Eliminates many failure conditions where clients may perform operations out of order.
Spring 2010 mark.baker@computer.org
Spring 2010
mark.baker@computer.org
Avoid creating custom representations. There are too few business-oriented media types today:
Craft business messages into XHTML, and/or embed in Atom!
Spring 2010
mark.baker@computer.org
POST is a problem:
Not safe or idempotent, A number of solutions have been developed, but none are widely in use POST Once Exactly (POE) and HTTPLR (Reliable Transmission).
Spring 2010
mark.baker@computer.org
Reach:
Low barrier to entry, Ubiquitous (programming languages, operating systems, servers, browsers, spreadsheets, news readers, mobile devices, etc.).
Spring 2010
Abuses (tunnels over) HTTP (yet uses the term web services):
Unable to leverage any HTTP benefits, Requires a whole new investment in infrastructure.
Spring 2010 mark.baker@computer.org
No versioning Trouble with binary data (SwA, DIME, MTOM) WSDL is the work of mad men UDDI: monstrously complex and unsuited for the job its deployed to do WS-Addressing: URIs done badly
mark.baker@computer.org
Spring 2010
REST Easy
Recommendations:
REST should be your default choice for distributed applications, REST is not a silver bullet. Use other solutions (e.g. Message-Oriented Middleware, WS-*) as requirements call for it:
MOM is good, Someday, not today, WS-* may make a "better MOM.
Spring 2010
mark.baker@computer.org