This document discusses Representational State Transfer (REST) and compares it to Service Oriented Architecture (SOA). It provides background on the early web and how REST emerged as a set of constraints for networked applications. It notes that REST is not a technology, standard, or product, but rather an architectural style. The document discusses core REST concepts like resources, representations, and stateless interactions over the uniform interface of HTTP. It addresses some common misconceptions about REST and whether it is only suited for simple use cases.

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

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

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

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

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

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

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

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

9. 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?

10. 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!

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

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

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

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

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

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

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

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

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

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

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

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

23. Common
Misconceptions

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

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

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

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

28. • 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

29. • 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

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

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

32. 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!

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

34. 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/