ReST vs SOA(P)
yawn ...
Instead ...
Facts and confused metaphors
for Understanding ReST

Early Web
• Human edited Files / Document Oriented
programatic output
• A patchy server opening up access to static
files
• Massive Upgrade to Human Knowlege,
Communication, and Transparency

Tech Progress
• CGI Scripts
• Screen scrapping clients
• Spiders, Robots, and Internet Duct-tape
• Dynamic HTML
• XHTML & XML formats
• CSS

Roy T. Fielding
Architectural Styles and the
Design of Network-based
Software Architectures
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
by Paul Downey

ReST is not
• A technology
• A set of standards
• COTS software
• A tooth paste
http://www.lostwackys.com/Wacky-Packages/die-cuts/Crust.htm

ReST is
• A series of constraints that defines a
specific flavor of system architecture
• Layered
• Client / Server Representational
e
• Code on Demand State
• Client Cache Transfer
• Stateless Server

ReST is Weak
Poor network latency
Difficult to identify authoritative response
Uniform Interfaces degrade performance
Lacks “mandatory extensions” - must understand
Optimized for course grained transmissions
Hard to customize

but also
ReST is Dope
because of
Low technical barrier to play
General Interfaces
Resource Extensibility
Massively Scalable
Independent Deployment

UnReST
Lastly in his Thesis Fielding identifies these issues with HTTP
• Cookies - enabled server side session
• Personalization
• Vendor specific extensions
Did the masses listen to academia?

A Common Path
/Server.do?some=stuff
RPC style Sessions
XML-RPC Large Controllers
SOAP Query String Param mappers
Form deserializers
Abstract away the network!

A Common Path?
• Focus on APIs, distributed transactions, etc
• Procedural code
• Distributed OOP
1992 called,
it wants it’s
CORBA
back ...

http://www.wisconsinhistory.org/whi/fullimage.asp?id=13487
RPC usually
fights the web
with Complexity
ReST Web Services are injected
into HTTP molds
with gooey Web2.0 filling

ReSTful Web Services?
Madge!
You’re suggesting there’s
issues with transporting
all my SOAP traffic over
POST through one URI?
Relax, SOAP document literal over HTTP
is the most popular.
But won’t I lose transport
independence?
Yes, but if you add using GET, more endpoints,
etc you can have caching for free!
via Shannon C. on Flickr

ReST in 90 seconds
• URIs
• Resources
• Representations
• State Transitions
• User agents, intermediaries, and servers
• Uniform Interfaces

Core Concepts
http://flickr.com/photos/68661927@N00/350737025/in/photostream/

URI
• Everything has a name
• Excel good C3 = B3 * B2
• Outlook bad - No address for “Last email
from RSDG”
• This presentation is available at
http://www.slideshare.net/ozten/slideshows

Resources
• Any “Thing” - concept, event, person
• Anything you would want to point too
• Request or Respose = data + metadata in
an envelope with control data
• Explicit request / response - no hidden
state
• Easier to load balance
• Easier to troubleshoot

Representations
• A serializable description of a Resource
• Modify resources through representations
• XHTML Microformats
• Industry standard binary formats ( jpg,
mpg, etc )
• JSON
• XML ( Atom or custom )
• The resource itself for static files

State Transitions
Hypermedia as the engine of
• Links
application state
• link, img, and a tags
• Forms
Links and forms are the hypermedia elements of
XHTML. They create the network effect of the web.
Every resource represents a state in your application.
State transition aren’t hidden behind an API, but are
instead transmitted back in forth in a hypermedia
protocol. Client’s can follow these links and be less
fragile to future changes. RPC usually lacks links and
encourages assumptions about formatting URI or
server states.

Client / Server
• User Agents
• Web browsers
• HTTP libraries - libwww, libcurl, etc
• Proxies
• Gateways
• Servers

Uniform Interfaces
HTTP Method Guarantee # Of Effects
0
GET, HEAD Safe
1
PUT, DELETE Idempotent
POST None ???
Möbius strip via wikipediajpg

So What?
Most popular example:
• Stateless Client / Server rules give us
• Client Side Cache
• HTTP 1.1 conditional GET
• Implement Etags, If-Modified-Since
• Real savings time, $, and complexity

Common
Misconceptions

But, Browsers only do
GET and POST
• Yep, their horrible ReST clients
• Web Developers use XMLHttpRequest for
PUT, DELETE, etc
• Outside of browser, use HttpClient,
libwww, or libcurl
• ReST uniform interface means
you can tunnel PUT, DELETE
over POST or write one off Proxy via cleansweepsupply.com

ReST is just CRUD
• Sure you can expose HTTP SQL CRUD
POST INSERT Create
DB on web
GET SELECT Read
• Too cute and simple PUT UPDATE Update
right? DELETE DELETE Delete
It’s about favoring protocols Refactor design to use
and resources over APIs.
new resources if you run
out of HTTP methods

Example
Requirment: A user can subscribe to an artist feed
ArtistWS.subscribeUserTo( User user, Feed feed )
POST /subscriptions
OR artist=Art.1234
feed=Feed.2345
email=false
Location: http://foo.com/subscription/Sub.3456
Artist - GET, PUT, DELETE
Feed - GET, PUT, DELETE
Subscription - GET, POST, PUT, DELETE
User - GET, POST, PUT, DELETE

We need WSDL for
ReST
• Yes, programmers need documentation and a way
to discover functionality
• ReST gets for free
• Uniform Interface
• Transparent data and HTTP tools
• Explicit state transitions
• Power of XML - XSD, extensibility, etc

• WSDL tries to hide network, parsing and
formating messages, loose typing
• Often WSDL is an afterthought, a verbose
format itself, used to generate incredibly
verbose SOAP payloads - Yeah tools!
• Doesn’t actually solve the really hard
problems, still need other WS-* specs
focused on such as transitions or security

• ReST still requires you to document your
resources, representations, and other highly
application specific details
• URI, Microformats, XSD, hypermedia, etc let
ReST clients do this in a lightweight manner
• URITemplates, XHTML 5, etc coming
• besides, WSDL2Foo is bad

WADL
• Don’t agree that WSDL2Foo is bad?
• OKAY, Use WADL
• WSDL like tool

Rare Conceptions
• ReST is nothing more than the web
circa 2003
• Human and programatic web both
thrive under ReST constraints
• It’s the Data, not the Source, not the
API, not the platform
• Mashups and ??? (future emergent techniques)
are easier with ReST

Surprise, you’re soaking
in it...
Everything we do
over HTTP is “ReST”,
but we can build
systems that work
with the natural form Call the police! These
of the web APIs are a crime!

ReST isn’t your
solution
• If your doing sophisticated mission critical
distributed programming with transactions
across multiple partners in synergistic fashion
• Use CORBA, EDI, Stateful protocol, etc
• Client and server written in Java? Use RMI, Jini,
etc
• Invent a new architecture by applying
constraints to derive a solution that works with
your problem space ala Chapter 5 of Fielding

Resources
•http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
•http://rest.blueoxen.net/
•http://microapps.org/
•http://bitworking.org/news/
•http://intertwingly.net/blog/
•http://www.tbray.org/ongoing/