Separating REST Facts from Fallacies

Alan Dean

The Web
Fallacy
REST is just The Web
Facts
Much / most of the Web is not RESTful
REST was described, a posteriori, by Roy Fielding in his doctoral thesis as the architectural principles underlying HTTP (edited by Fielding et al )
http://www.ics.uci.edu/~fielding/pubs/dissertation/
REST is The Web done right

Authoritative
Fallacy
REST is a matter of opinion
Fact
REST is what Roy says it is

REST is an Architectural Style
An architectural style is a coordinated set of architectural constraints that restricts the roles and features of architectural elements, and the allowed relationships among those elements, within any architecture that conforms to that style.
A style can be applied to many architectures.
An architecture can consist of many styles.

Deriving REST
Style = nil
Style += Client/Server
Style += Stateless
Style += Caching
Style += Uniform Interface
Style += Layered System
Style += Code on Demand

Style = nil
Starting from a condition of no constraints…

Style += Client/Server
Apply separation of concerns
improves UI portability simplifies server enables multiple organizational domains

REST & HTTP
Fallacy
REST == HTTP
Fact
“ Good grief. Why does everyone equate REST with HTTP? REST apps work quite well with file, ftp, gopher, wais, urn, ... I won't even mention waka in that list because it isn't done yet.”
(Roy Fielding)
HTTP is simply the best known Transfer protocol

Style += Stateless
Constrain interaction to be stateless
simplifies server improves scalability improves reliability degrades efficiency

Stateless
It is important to differentiate (client) application state from (server) resource state
Fallacy
You can do an end-around of the stateless constraint by turning application state into resource state
Fact
The server should have no knowledge about application state
The client is free to use a different server to persist application state

Style += Caching
Add optional non-shared caching
reduces average latency improves efficiency improves scalability degrades reliability $ $

Style += Uniform Interface
Apply generality
degrades efficiency improves visibility independent evolvability decouples implementation $ $ $

Uniform Interface
Uniform identification of resources
Uniform access methods
Universal semantics
Manipulation of resources through the exchange of representations
Self-descriptive messages
Hypermedia / hypertext as the engine of application state

Uniform identification of resources
All important resources are identified by one (uniform) resource identifier mechanism, e.g. a URI
Fallacy
The layout of the URI is important to REST
Facts
The layout of the URI is opaque to REST
A ‘human-friendly’ URI is good, regardless

Uniform access methods
Actions mean the same for all resources
Fallacies
Methods IN { PUT, GET, POST, DELETE }
Therefore, REST == CRUD
Facts
Any universally understood representation action can be used, e.g.:
WebDAV LINK or PATCH but not PROP
COM IDispatch and IUnknown can be regarded as uniform COM object ‘GET’ access methods
Some HTTP methods are insufficiently defined
Yes, I’m talking “POST” aka “MISCELLANEOUS”

Hypermedia / hypertext as the engine of application state
Often abbreviated to HATEOAS
Think about media-types
Fallacies
Hypertext == HTML
Atom everywhere
Facts
Explicit or implicit links support HATEOAS
Links exist in non-HTML media-types
There are more media types than just HTML and Atom

Roy Fielding on HATEOS
“ A truly RESTful API looks like hypertext.
Every addressable unit of information carries an address , either explicitly (e.g., link and id attributes) or implicitly (e.g., derived from the media type definition and representation structure).
Query results are represented by a list of links with summary information , not by arrays of object representations (query is not a substitute for identification of resources).
Resource representations are self-descriptive : the client does not need to know if a resource [belongs to a specific website] because it is just acting on the representations received.”

Style += Layered System
Apply information hiding
shared caching improves scalability adds latency simplifies client legacy encapsulation load balancing $ $ $ $ $ $ $ $ $

Style += Code on Demand
Allow code-on-demand (applets/js)
simplifies clients reduces visibility improves extensibility $ $ $ $ $ $ $ $ $ .js

Simplicity
Fallacy
REST is simple
Facts
REST has simple constraints
RESTful systems are often complex in their collaborations
Truly RESTful system design is non-trivial

Difficulty
Fallacy
REST is easy
Fact
All distributed system development is hard
http://wikipedia.org/wiki/Fallacies_of_Distributed_Computing
REST is not a panacea

Plain Old XML (POX)
Fallacy
REST is just POX-over-HTTP
Facts
POX (as generally understood) is typically an RPC style
POX typically tunnels through HTTP using POST
With endpoints that look & act like methods
Without meeting the constraints of REST
Content-Type: application/xml is a tell

hi-REST / lo-REST
Fallacy
The hi-REST / lo-REST meme
Started by Don Box
Fact
“ REST, as styles go, is more like the architecture of barnyards and office suites. The notion that there is anything lo or hi about it demonstrates a fundamental lack of understanding”
(Roy Fielding)
You are either RESTful, or not
You become RESTful by not breaching any constraint

SOAP Services (WS-*)
Fallacies
Commit to REST or WS-*
REST is the ‘ultimate architecture’
Facts
WS-* is not an architectural style
SOA == REST nil style
REST is not a protocol stack
REST is appropriate when a Resource Oriented Architecture (ROA) is desirable
A system can compose both REST and WS-*
We are in a world where some architects still think you need to commit to one or the other

Standardization
Fallacy
Unlike WS-*, REST has no standards
Facts
Hymermedia / hypertext is standardized
fewer UIs
Identification is standardized
less communication
Exchange protocols are standardized
fewer integrations
Interactions are standardized
fewer semantics
Media-types are standardized
fewer translations

Man –vs- Machine
Fallacy
RESTful systems are only good for systems which require human interaction, like web pages
Fact
A well-written RESTful application protocol will sufficiently remove ambiguity to allow machine-to-machine interaction
AtomPub achieves this
RSS is the counter-example

Interface Definitions
Fallacy
REST needs a WSDL such as WADL
Fact
The whole point of the Uniform Interface constraint is to remove the need for specialised interface definitions

Authentication
Fallacy
It’s OK to use server cookies to authenticate users in REST
Fact
“ Authentication is orthogonal. Cookies are also orthogonal when they are simply used for content negotiation or authentication. However, Cookie authentication is not allowed in REST because it lacks visibility, which causes security problems […]”
(Roy Fielding)
For HTTP, use WWW-Authenticate

Scalability
Fallacy
RESTful services always scale well
Fact
Not unless you have implemented caching
Not if interaction requires access control

Transactions
Fallacy
You can’t do transactions in REST
Facts
You can do atomic server transactions within the bounds of a single HTTP request
You can do compensatory ‘long-running’ and distributed transactions across multiple HTTP requests provided that you don’t break the Layered System constraint

Tools
Fallacy
REST needs more tooling before adoption
Fact
The tooling to implement REST on HTTP already exists
However, developers need to throw off their current mindset and understand REST
The on-ramp to REST can be made easier with better tools
ASP.NET MVC is superior to ASP.NET WebForms

Adoption
Facts
Many systems could benefit by adopting a RESTful architecture
Acceptance and adoption has been slow
This is now changing
Beware of the gloryhounds who follow buzzwords but don’t actually grok REST
Do you ETag?
REST is not easy to learn, especially when a previous mindset needs to be set aside
Too many sites wrongly claim a RESTful API

</presentation>
Email
[email_address]
Links
http://delicious.com/alan.dean/rest
http://alandean.blogspot.com
http://twitter.com/adean
Acknowledgements
“ A little REST and Relaxation”
Roy Fielding, 2007 ApacheCon

http://alandean.blogspot.com	206
http://www.slideshare.net	12
http://alandean.blogspot.co.uk	4
http://alandean.blogspot.it	1
http://alandean.blogspot.hk	1
https://si0.twimg.com	1
http://alandean.blogspot.jp	1
http://alandean.blogspot.ca	1

Separating REST Facts from Fallacies

by Alan Dean

Accessibility

Categories

Upload Details

Usage Rights

8 Embeds 227

Statistics

Separating REST Facts from Fallacies Presentation Transcript