grokking the rest architectural style
DESCRIPTION
REST has become the hip, new buzzword of Web 2.0. But what makes an application RESTful? Pretty URLs? XML over HTTP? Any service that's not SOAP? In all the hype, the definition of REST has become clouded and diluted. Forget what you thought you knew about REST. In this talk, Ben Ramsey reintroduces REST, placing it under a microscope, uncovering each constraint that forms REST's crucial principles. Ramsey explains how REST is a style for network-based software applications, emphasizing scalability and efficiency through separation of concerns and taking advantage of the Web as a platform for rich Internet applications.TRANSCRIPT
Ben Ramsey ■ Dutch PHP Conference ■ 12 June 2009
Grokking theREST Architectural Style
Yes.
I am this guy.
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.
Client-serverSeparated, by Hansol Lee
Stateless
Stateless by Koesmanto Bong
Cache
Cache County, Utah by J. Stephen Conn
used to interface, by Tom Hensel
Uniform Interface
1.Identification of resources2.Representation of resources3.Linked resources4.Resource metadata
Layered
Sedimentary Layers by Mark Thurman
Code-on-demandjeremyʼs tie by Gitchel
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
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
Resource-orientedDesign
1. Determine your resources
User Content
/users/users/{username}
/content/content/{ID}
Before we had CAD, we had Lead!, by Wendell
2. Decide the methods for each resource
/users
GETPOST
/content
GETPOST
/users/{username}
GETPUTDELETE
/content/{ID}
GETPUTDELETE
Before we had CAD, we had Lead!, by Wendell
Resource-orientedDesign
3. Link your resources
Before we had CAD, we had Lead!, by Wendell
Resource-orientedDesign
Users own content
Each user owns multiple content items
Each content item has one owner
4. Determine your data schemas
Before we had CAD, we had Lead!, by Wendell
User Content
idusernamefirstnamelastname
idownertitlefile/content
Resource-orientedDesign
5. Choose your content type(s)
Before we had CAD, we had Lead!, by Wendell
Resource-orientedDesign
In conclusion...
Conclusion, by Mark Cummins
Grokking the REST Architectural StyleCopyright © Ben Ramsey. Some rights reserved.
This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.
For uses not covered under this license, please contact the author.