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

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

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.

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

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…

Starting from a condition of no constraints…

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

Apply separation of concerns

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

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

Constrain interaction to be stateless

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

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 $ $

Add optional non-shared caching

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

Apply generality

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

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

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”

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

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.”

“ 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 $ $ $ $ $ $ $ $ $

Apply information hiding

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

Allow code-on-demand (applets/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

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

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

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

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

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

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

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

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

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

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

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

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

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

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