lecture 14 - rest

8/3/2019 Lecture 14 - REST

1/34

XML and Web Technologies

Prof Mark Baker

ACET, University of ReadingTel: +44 118 378 8615E-mail: [email protected]

Web: http://acet.rdg.ac.uk/~mab

Lecture 14: RESTful Services

http://acet.rdg.ac.uk/~mab/Education/Undergraduate/CS2K7/Lectures/

Spring 2010 [email protected]


2/34

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 allowedrelationships among those elements within anyarchitecture that conforms to that style.

or an abstraction, a design pattern, a way of discussing an

architecture without concern for its implementation.



3/34

Understanding REST

What is REST? REST defines a series of constraints for

distributed systems that together achieve theproperties 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 moreor less RESTful: REST is not a set of laws or even a specification it is

a style



4/34

Understanding REST

Representational State Transfer: The Resource:

A resource is any information that can be named:documents, images, services, people, an collections.

Resources have state:

State may change over time. Resources have identifiers:

A resource is anything important enough to be referenced.

Resources expose a uniform interface:

System architecture simplified, visibility improved, Encourages independent evolution of implementations.



5/34

Understanding REST

Representational State Transfer: On request, a resource may transfer a

representation of its state to a client: Necessitates a client-server architecture.

A client may transfer a proposed representation

to a resource: Manipulation of resources through representations.

Representations returned from the server shouldlink to additional application state:

Clients may follow a proposed link and assume a newstate Hypermedia as the engine of application state.



6/34

Understanding REST

Representational State Transfer: Stateless interactions:

Each request from client to server must contain all of theinformation necessary to understand the request, andcannot take advantage of any stored context on theserver.

Statelessness necessitates self-descriptivemessages:

Standard media types,

Meta-data and control-data.

Uniform interface + Stateless + Self-descriptive =Cacheable:

Cacheable necessitates a layered-system.



7/34

Understanding REST

What is REST:

REST is a coordinated set of architectural constraintsthat attempts to minimise latency and networkcommunication while at the same time maximizing theindependence and scalability of componentimplementations. .

REST enables the caching and reuse of interactions,dynamic substitutability of components, and processing ofactions by intermediaries, thereby meeting the needs ofan Internet-scale distributed hypermedia system (RoyFielding),

Principal author of the HTTP 1.0, HTTP 1.1, and URI spec.

Co-founder of The Apache Software Foundation.



8/34

Using HTTP to build REST Applications

What distributed systems protocol supportsthe implementation of REST applications?

HTTP 1.1aka RFC 2616

URIs: RFC 3986

MIME: RFCs 2045/2046

Media Types (multiple RFCs, IANA)



9/34


What HTTP is:

Purposefully designed,

REST conformant,

Frequently abused,

Wildly successful, An application protocol.



10/34


HTTP: A brief introduction: A stateless, client/server, request/response

application protocol,

Clients make requests of servers using four mainoperations (uniform interface):

GET, POST, PUT, DELETE (there are others),

A request is sent to a specified URI(addressabilty),

An HTTP request/response is an envelope,

Inside the envelope are headers followed by aresource representationif any (self-descriptive).



11/34


The REST Recipe: Find all the nouns,

Define the formats,

Pick the operations,

Highlight exceptional status codes.



12/34


Find all the nouns: Everything in a RESTful system is a resource a

noun.

Every resource has a URI,

URIs should be descriptive:

http://example.com/expenses;pending

Not a REST principle, but a good idea!

URIs should be opaque: automated (non-human) clients should not infer meaning

from a URI.



13/34


Find all the nouns:

Use path variables to encode hierarchy:/expenses/123

Use other punctuation to avoid implying hierarchy:/expenses/Q107;Q307

/expenses/lacey,peter

Use query variables to imply inputs into an algorithm:/search?approved=false

Caches tend to (wrongly) ignore URIs with queryvariables!

URI space is infinite (but URI length is not ~ 4K).



14/34


Resource URI

Bill's expense reports /users/bill/expenses

Expense report #123 /users/bill/expenses/123

All expense reports (you'reallowed to see)

/expenses/

All pending (new, etc.) expensereports

/expenses;pending (new, etc.)

Bill's pending expense reports /users/bill/expenses;pending

Expense 123s line items /users/bill/expenses/123/line_items

Line item 2 of Expense 123 /users/bill/expenses/123/line_items/2

2006 expenses /2006/expenses/

2006 open expenses /2006/expenses;submitted


15/34


Define the formats:

Neither HTTP nor REST mandate a singlerepresentation for data.

A resource may have multiple representations: XML, JSON, binary (e.g., jpeg), name/value pairs

Schema languages are not required (if evenpossible). 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.



16/34


Pick the operations: HTTP has a constrained user interface (set of

verbs/operations/methods): GET,

POST,

PUT, DELETE,

HEAD,

OPTIONS (not widely supported),

TRACE (not significant),

CONNECT (not significant).

All of our resources will support GET!



17/34


GET returns a representation of the current

state of a resource. GET is safe:

Does not change resource state,

May trivially change server side state, e.g. log files, GET is idempotent: Multiple requests are the same as a single request,

Might be impacted by concurrent operations.

NEVER violate these rule.



18/34


Highlight exceptional status codes: HTTP has more response codes than 200 and 404

learn them: Information: 1xx, Success 2xx, Redirection 3xx, Client

Error 4xx, Server Error 5xx;

For GETs we will need: 200 OK,

204 No Content,

404 Not Found,

Well need more later.



19/34


REST Frameworks: It is possible and legitimate to build REST systems

with any HTTP-enabled application environment. Few frameworks now, but more everyday:

RESTlet (Java, open source)

Ruby on Rails (Ruby, open source) Django (Python, open source) CherryPy (Python, open source) JSR 311/JAX-RS (Java) Astoria (.NET, Microsoft labs project)

Project Zero (Groovy/PHP, IBM incubator project) .NET 3.5 (aka Orcas, unreleased) Tycho (Reading system).



20/34

REST Concepts and Practices

Addressability:

Every resource that your application managesshould be exposed via a URI,

Every URI you provide is a de facto resource, codeaccordingly,

The URI space is infinite, Multiple representations of a single resourceshould be uniquely addressable,

URIs are understood by almost all software, URIs can be: written down, memorised, emailed,

bookmarked, piped into other apps.



21/34


On Statelessness: Every request happens in isolation:

Client maintains application state,

All information required by a resource is in the request,

Server does not use information from previous requests.

The possible states of a server are also resources, andhave 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. Lights that are on at this moment: /lights/currently_on

Eliminates many failure conditions where clients mayperform operations out of order.



22/34


On Statelessness:

Stateless applications can be load-balanced,partitioned, scaled, cached: More easily allows for active-active disaster recovery.

Sessions are to be avoided: Sessions are servers maintaining client-side state,

Message is no longer self-descriptive, Server may respond differently to identical requests based on

session.

Server should forget about clients between requests: No cookies,

No session keys in URI or request data. Be very careful if breaking the statelessness

constraint: Impacts reliability, scalability, performance.



23/34


Self-descriptive messages:

Message semantics visible without looking at themessage body:

Headers describing messages and content, Statelessness, Standard methods,

Standard media types. Enables support for intermediation:

Cache knows it can cache GETs, but not POSTs, Cache knows freshness information, Compression engine can choose best technique for content

type, Gateway can reject requests for non-English content.



24/34


Self-descriptive messages: representations and

media types: Try and use well-known media types:

Makes content more accessible, Part of the self-descriptive messaging constraint.

Avoid creating custom representations. There are too few business-oriented media typestoday:

Craft business messages into XHTML, and/or embed inAtom!

Incoming representations should be the same asoutgoing representations: A client should be able to GET, modify, and PUT a document, Server should discard any extraneous data.



25/34


The Uniform Interface:

All resources present the same external interface, Creates a network:

Anyone can play to some degree, Encourages network effects.

HTTP verbs are constrained in how they impactresources: Safety (GET):

Simply: No change to server-side state, Precisely: Client not responsible for changes to server-side

state.

Idempotency (PUT, DELETE): More than one request is the same as one request.

Developer is responsible for assuring these constraints, POST is not constrained.



26/34


The Uniform Interface: GET and POST are all you really need to be

RESTful: Get state / change state,

PUT and DELETE are handy optimisations.

Avoid overloading POST.



27/34


Reliable Messaging: HTTP is an unreliable protocol:

No mechanism for determining if sent message wasreceived.

But GET, PUT, and DELETE are intrinsically reliable:

GET is safe and idempotent, call it till you get a response, PUT and DELETE are idempotent, call them till you get a

response.

POST is a problem: Not safe or idempotent,

A number of solutions have been developed, but none arewidely in use POST Once Exactly (POE) and HTTPLR(Reliable Transmission).



28/34

REST, WS-*, and SOA

Why REST/HTTP is good: Meets the requirements specified of it:

Scalable, high-performing, evolvable, visible, reliable, simple.

Uses existing infrastructure: Cache engines, firewalls, SSL accelerators, monitoring, load

balancers, etc. Reach:

Low barrier to entry,

Ubiquitous (programming languages, operating systems,servers, browsers, spreadsheets, news readers, mobile

devices, etc.). Addressable - URIs make the Web

Interoperable.

Extensible.Spring 2010 [email protected]


29/34

REST, WS-*, and SOA

Current REST Limitations: Developer tooling is limited, Requires developers to think differently,

Dearth of organised documentation,

Security too limited,

Some of HTTP's pre-existing syntax,

Content negotiation does not quite work,

POST is non-idempotent,

Support for PUT and DELETE, Could use a PATCH method,

Not natively asynchronous,

Response messages do not indicate request,



30/34

REST, WS-*, and SOA

REST vs SOAP and WS-* As a means for building out wide-scale, reusable

distributed systems, WS-* is seriously flawed. Flaw: Undesigned / without constraints:

Does not provably exhibit any non-functional

requirement (scalability, etc.): Empirical evidence suggests this is true!

Not scalable or reliable: Cannot be partitioned, not stateless,

Not performant: Cannot be cached,

Not evolvable.

Abuses (tunnels over) HTTP (yet uses the term webservices):

Unable to leverage any HTTP benefits,

Requires a whole new investment in infrastructure.



31/34

REST, WS-*, and SOA

REST vs SOAP and WS-*

Flaw: Poorly specified: Too many overly complex specifications,

Solving problems no one has: e.g distributed transactions,and BPEL,

Not very interoperable, even with just SOAP, Married too closely to XML Schema Difficult, brittle

Type systems dont work across languages

No versioning

Trouble with binary data (SwA, DIME, MTOM) WSDL is the work of mad men

UDDI: monstrously complex and unsuited for the job itsdeployed to do

WS-Addressing: URIs done badly



32/34

REST, WS-*, and SOA

REST vs SOAP and WS-*

Flaw: Marketing: Vendor wars, Over promised, over sold, and over due, Tools encourage backwards (code first) development, Tools discourage use of XML tooling: XPath, XSLT,

XQuery, etc. Flaw: Every endpoint is its own private network

Clients tightly bound to servers not evolvable, No reach, accessible by programmers only (barely), SOAP resources are not addressable:

Do not enrich the Web. Effectively not there, No notion of links: No spidering, search, bookmarking,

tagging. etc., Every end point is a terminal point.

WS-Merits - WS-Security is OK.



33/34

REST, WS-*, and SOA REST and SOA:

SOA is not about technologies: WS-*, REST, CORBA, etc. can be used,

Use REST instead of WS-*: Infinitely simpler,

More accessible,

Leverages existing infrastructure, Actually works,

Requires less governance.

SOA leverages a managed communication infrastructure

(MCI): XML gateways, SOA management systems, enterprise service

busses

REST MCI equally available, battle hardened, already inplaceSpring 2010 [email protected]


34/34

REST Easy

Recommendations:

REST should be your default choice for distributedapplications,

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.

Use SOAP/WS-* to integrate with existing

SOAP/WS-* applications,


lecture 14 - rest

Documents