Separating REST Facts from Fallacies

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

Separating REST Facts from Fallacies

More Related Content

What's hot

Viewers also liked

Similar to Separating REST Facts from Fallacies

More from Alan Dean

Recently uploaded

Separating REST Facts from Fallacies