you look like you could use some rest!
DESCRIPTION
Representational State Transfer, or REST, has become the hip, new buzzword of Web 2.0. But what really makes an application RESTful? Is it pretty URLs? Or the use of XML over HTTP? Is it any web service that doesn't use SOAP? In all of the hype, the definition of REST has become clouded and diluted. It's time to take a fresh look at REST. In this talk, Ben Ramsey reintroduces REST and its architectural style. He shows that REST is not only an architecture for web services but that it describes an architecture for the Web. Ramsey will demonstrate how statelessness, a resource-oriented architecture, atomicity of requests, and other traits of REST make the most of the Web's architecture to provide scalable and simpler web services turning the Web into a platform by which rich clients can access and manipulate data.TRANSCRIPT
Ben Ramsey ■ php|works PyWorks ■ 13 November 2008
You Look Like YouCould Use Some REST!
REST
Roatan Beach - Perfect Day, by Janusz Leszczynski
Tom Coates, by Patrick Lauke
Is it about pretty URLs?
Web Developer Gang Sign, by Josh Lewis
How about XML over HTTP?
#webdevgangsign
A Bar of Ivory Soap, by iirraa
Any web service that’s not SOAP?
RepresentationalState Transfer
Restful Summer, by Clear Inner Vision
Theoryof REST
Public Domain, from Wikimedia Commons
REST defines a style by which a resource’s state may be transferred using a representation of that resource.
REST defines a style by which a resource’s state may be transferred using a representation of that resource.
REST defines a style by which a resource’s state may be transferred using a representation of that resource.
Back on the Log Train, by Claire L. Evans
Resources
Addressable
Address:1304, by Grant Hutchinson
used to interface, by Tom Hensel
Uniform Interface
Separated, by Hansol Lee
Client-serverStatelessCacheableLayered
Sand Banks Sunset, by Clear Inner Vision
RESTful Benefits
Improved response time & reduced server load
Improves server scalability
Requires less client-side software
Depends less on vendor software
No need for resource discovery
Better long-term compatibility & evolvability than RPC
A Real-World Analogy
Money!, by Tracy Olson
RESTfulPractice
Public Domain, from Wikimedia Commons
Drip Drops and the Spider Web, by Mike Bitzenhofer
“[REST] is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.” — Roy Fielding
Hypertext Transfer Protocol
#110 Hypertext Transfer Protocol, by maako
URIs provide unique addresses
Constrained interface with methods and content types
Transactions are atomic
Built-in support for layering
Provides for cache control
HTTP Interface
#110 Hypertext Transfer Protocol, by maako
Methods
GETPUTPOSTDELETE
Cut & Paste
CopyPaste OverPaste AfterCut
HTTP Interface
#110 Hypertext Transfer Protocol, by maako
Transfers (copies) a representation of a resource from server to client
GET
Body must contain enough information for the client to usefully operate on the data
Considered safe
Has the property of idempotence
HTTP Interface
#110 Hypertext Transfer Protocol, by maako
Transfers the state from client to the server (equivalent to paste over)
PUT
The body must contain enough information for the server to operate on the data
May also create a new resource at the requested URI
Has the property of idempotence
HTTP Interface
#110 Hypertext Transfer Protocol, by maako
Has the same meaning as paste after
POST
May create or update resources, depending on context
Is not idempotent
HTTP Interface
#110 Hypertext Transfer Protocol, by maako
Acts like cut
DELETE
Requests that the resource identified be destroyed or removed from public web
Has the property of idempotence
Idempotence
#110 Hypertext Transfer Protocol, by maako
Not a sexual dysfunction
The side-effects of N > 0 identical requests is the same as for a single request
That is: every time you make the request, as long as it is an identical request, exactly the same action occurs
Content Types
#110 Hypertext Transfer Protocol, by maako
HTTP supports content types through the Content-Type header
A single resource can be transferred in various content types
Content negotiation used to tell the server what type to return to the client
REST community doesn’t care for content negotiation
#110 Hypertext Transfer Protocol, by maako
1
POST /content HTTP/1.1Host: example.orgContent-Type: application/xml
2
HTTP/1.x 201 CreatedDate: Thu, 13 November 2008 16:43:56 GMTLocation: /content/1234
Lifecycle of a Resource
#110 Hypertext Transfer Protocol, by maako
3
GET /content/1234 HTTP/1.1Host: example.org
4
HTTP/1.x 200 OKDate: Thu, 13 November 2008 16:44:13 GMTContent-Type: application/xml
Lifecycle of a Resource
#110 Hypertext Transfer Protocol, by maako
5
PUT /content/1234 HTTP/1.1Host: example.orgContent-Type: application/xml
Lifecycle of a Resource
6
HTTP/1.x 200 OKDate: Thu, 13 November 2008 16:48:26 GMTContent-Type: application/xml
#110 Hypertext Transfer Protocol, by maako
7
DELETE /content/1234 HTTP/1.1Host: example.org
Lifecycle of a Resource
8
HTTP/1.x 204 No ContentDate: Thu, 13 November 2008 16:50:47 GMT
Resource-oriented Architecture
Where I Teach, by Todd Ehlers
1. Represent itself to the client
2. Transition from one state to the next
3. Destroy itself
Additionally, the system knows how to create a resource.
Resource-oriented Architecture
Where I Teach, by Todd Ehlers
Resources are addressable
Resources have no state
Resources are connected
Resources share the same interface
Resource-oriented Architecture
Where I Teach, by Todd Ehlers
Query string parameters appropriate in some cases
Pragmatic use of URIs instead of using HTTP headers
RPC-style APIs are avoided
Representation should have links
URI templates specify URI families
Resource-oriented Architecture
Where I Teach, by Todd Ehlers
Should expose many URIs
Session cookies are not RESTful
Combined resources are RESTful only if represented as a URI
URIs should facilitate “cut & paste”
Atom
A resource-oriented protocol for publishing documents that sits on top of HTTP
Molecule display, by Christian Guthier
Atom
Entry Documentapplication/atom+xml;type=entry
Molecule display, by Christian Guthier
Feed (Collection) Documentapplication/atom+xml;type=feed
Category Documentapplication/atomcat+xml
Service Documentapplication/atomsvc+xml
1
GET /index.atom HTTP/1.1Host: example.org
2
HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:13:14 GMTContent-Type: application/atomsvc+xml
Atom Resource Lifecycle
Molecule display, by Christian Guthier
3
GET /archives.atom HTTP/1.1Host: example.org
4
HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:13:46 GMTContent-Type: application/atom+xml;type=feed
Atom Resource Lifecycle
Molecule display, by Christian Guthier
5
GET /categories.atom HTTP/1.1Host: example.org
6
HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:13:48 GMTContent-Type: application/atomcat+xml
Atom Resource Lifecycle
Molecule display, by Christian Guthier
7
POST /archives.atom HTTP/1.1Host: example.orgContent-Type: application/atom+xml;type=entry
8
HTTP/1.x 201 CreatedDate: Thu, 13 November 2008 17:16:32 GMTLocation: /archives/1234.atom
Atom Resource Lifecycle
Molecule display, by Christian Guthier
9
10
HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:16:36 GMTContent-Type: application/atom+xml;type=entry
Atom Resource Lifecycle
GET /archives/1234.atom HTTP/1.1Host: example.org
Molecule display, by Christian Guthier
11
12
HTTP/1.x 200 OKDate: Thu, 13 November 2008 17:23:12 GMTContent-Type: application/atom+xml;type=entry
Atom Resource Lifecycle
PUT /archives/1234.atom HTTP/1.1Host: example.orgContent-Type: application/atom+xml;type=entry
Molecule display, by Christian Guthier
13
14
HTTP/1.x 204 No ContentDate: Thu, 13 November 2008 19:34:29 GMT
Atom Resource Lifecycle
DELETE /archives/1234.atom HTTP/1.1Host: example.org
Molecule display, by Christian Guthier
RESTfulDesign
1. Determine your resources
User Content/users/users/{username}
/content/content/{ID}
Before we had CAD, we had Lead!, by Wendell
RESTfulDesign
2. Decide the methods for each resource
/usersGETPOST
/contentGETPOST
/users/{username}GETPUTDELETE
/content/{ID}GETPUTDELETE
Before we had CAD, we had Lead!, by Wendell
RESTfulDesign
3. Connect your resources
Before we had CAD, we had Lead!, by Wendell
RESTfulDesign
4. Determine your data schemas
Before we had CAD, we had Lead!, by Wendell
RESTfulDesign
5. Choose your content type(s)
Before we had CAD, we had Lead!, by Wendell
In Conclusion...
It’s all about resources.
Conclusion, by Mark Cummins
There’s More To Learn
Authentication
Digital signing
Encryption
WSDL 2.0 & WADL
