REST (Representational State Transfer) Neil Ernst Some material from Costello and Kehoe, John Cowan, Roy Fielding, Paul Prescod

Why REST? “… the web is an existence proof of a massively scalable distributed system that works really well, and we can take ideas from that to build integrated systems more easily.” – Martin Fowler http://martinfowler.com/articles/richardsonMaturityModel.html

The HTTP API HTTP provides a simple set of operations. GET = retrieve a resource (idempotent) POST = store a new/updated resource PUT = store a resource at a URI (idempotent) DELETE = remove this resource (idempotent) The HTTP API can implement CRUD - (Create, Retrieve, Update, and Delete) We’ll discuss ‘resource’ in a sec. PUT is often used for “update” and post for “create”, but that isn’t totally accurate. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Idempotence An operation that can be applied multiple times without changing the result after the first application E.g. floor(x) where x is a real number Subtract average from a list of numbers PUT/GET/DEL operations are by definition idempotent E.g. GET http://www.cnn.com/index.htm does not change the resource.

Nouns and verbs Two choices: RPC – model the API using verbs – the operations E.g. setCustomer(c_id, name, address) Must define the data elements as well “RESTful” model the API nouns – the data representation and state – and keep ops simple Eg. PUT issue/{id} Leverage the scalability of the HTTP infrastructure Caching, third-party libraries Simplify one part of the API The point, or one of them

Copyright 2005 John Cowan under GPL Two views of POST “POST lets you pass a whole lot of parameters and get something back, bypassing caches.” “POST lets you create new resources that are related to old ones.” The second is the REST attitude

What is REST? " REST " was coined by Roy Fielding in his Ph.D. dissertation [1] to describe an arch. style for implementing networked systems. [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Copyright 2005 John Cowan under GPL REST principles Resources are identified by uniform resource identifiers (URIs) Resources are manipulated through their representations Messages are self-descriptive and stateless Multiple representations are accepted or sent Hypertext As The Engine Of Application State (HATEOAS) A represnetation can be many forms, but most resources only have one, and so far, it tends to be JSON. XML also common.

REST design criteria Support a distributed ‘web’ of hypermedia documents numbering in the billions. Layered separation to support independent evolution Replication and caching to support scaling. Universal, limited set of operations to support extensibility. Stateless to support independent processing.

Why is it called "Representational State Transfer? " Resource Client http://www.boeing.com/aircraft/747 Fuel requirements Maintenance schedule ... Boeing747.html The Client references a Web resource using a URL. A representation of the resource is returned (in this case as an HTML document). The representation (e.g., Boeing747.html) places the client in a new state. When the client selects a hyperlink in Boeing747.html, it accesses another resource. The new representation places the client application into yet another state. Thus, the client application transfers state with each resource representation.

Representational State Transfer "Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use." - Roy Fielding