1. The document discusses the REST (Representational State Transfer) architectural style, which defines a set of constraints for designing web services.
2. Under REST, resources are addressed using URIs and can be represented in different data formats. Standard HTTP methods like GET, PUT, POST and DELETE are used to manipulate resources.
3. REST services aim to have stateless operations, cache responses, and separate clients and servers. This improves scalability and evolvability compared to RPC-style APIs.
16. 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 Sand Banks Sunset, by Clear Inner Vision
18. RESTful
Practice
Public Domain, from Wikimedia Commons
19. “[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
Drip Drops and the Spider Web, by Mike Bitzenhofer
20. Hypertext
Transfer
Protocol
URIs provide unique addresses
Constrained interface with methods and
content types
Transactions are atomic
Built-in support for layering
Provides for cache control
#110 Hypertext Transfer Protocol, by maako
21. HTTP Interface
Methods Cut & Paste
GET Copy
PUT Paste Over
POST Paste After
DELETE Cut
#110 Hypertext Transfer Protocol, by maako
22. Content Types
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
23. Lifecycle of a Resource
1
POST /content HTTP/1.1
Host: example.org
Content-Type: application/xml
2
HTTP/1.x 201 Created
Date: Thu, 13 November 2008 16:43:56 GMT
Location: /content/1234
#110 Hypertext Transfer Protocol, by maako
24. Lifecycle of a Resource
3
GET /content/1234 HTTP/1.1
Host: example.org
4
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 16:44:13 GMT
Content-Type: application/xml
#110 Hypertext Transfer Protocol, by maako
25. Lifecycle of a Resource
5
PUT /content/1234 HTTP/1.1
Host: example.org
Content-Type: application/xml
6
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 16:48:26 GMT
Content-Type: application/xml
#110 Hypertext Transfer Protocol, by maako
26. Lifecycle of a Resource
7
DELETE /content/1234 HTTP/1.1
Host: example.org
8
HTTP/1.x 204 No Content
Date: Thu, 13 November 2008 16:50:47 GMT
#110 Hypertext Transfer Protocol, by maako
27. Resource-oriented
Architecture
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.
Where I Teach, by Todd Ehlers
28. Resource-oriented
Architecture
Resources are addressable
Resources have no state
Resources are connected
Resources share the same interface
Where I Teach, by Todd Ehlers
29. Resource-oriented
Architecture
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
Where I Teach, by Todd Ehlers
30. Resource-oriented
Architecture
Should expose many URIs
Session cookies are not RESTful
Combined resources are RESTful only if
represented as a URI
URIs should facilitate “cut & paste”
Where I Teach, by Todd Ehlers
33. Atom Resource Lifecycle
1
GET /index.atom HTTP/1.1
Host: example.org
2
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:14 GMT
Content-Type: application/atomsvc+xml
Molecule display, by Christian Guthier
34. Atom Resource Lifecycle
3
GET /archives.atom HTTP/1.1
Host: example.org
4
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:46 GMT
Content-Type: application/atom+xml;type=feed
Molecule display, by Christian Guthier
35. Atom Resource Lifecycle
5
GET /categories.atom HTTP/1.1
Host: example.org
6
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:13:48 GMT
Content-Type: application/atomcat+xml
Molecule display, by Christian Guthier
36. Atom Resource Lifecycle
7
POST /archives.atom HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
8
HTTP/1.x 201 Created
Date: Thu, 13 November 2008 17:16:32 GMT
Location: /archives/1234.atom
Molecule display, by Christian Guthier
37. Atom Resource Lifecycle
9
GET /archives/1234.atom HTTP/1.1
Host: example.org
10
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:16:36 GMT
Content-Type: application/atom+xml;type=entry
Molecule display, by Christian Guthier
38. Atom Resource Lifecycle
11
PUT /archives/1234.atom HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
12
HTTP/1.x 200 OK
Date: Thu, 13 November 2008 17:23:12 GMT
Content-Type: application/atom+xml;type=entry
Molecule display, by Christian Guthier
39. Atom Resource Lifecycle
13
DELETE /archives/1234.atom HTTP/1.1
Host: example.org
14
HTTP/1.x 204 No Content
Date: Thu, 13 November 2008 19:34:29 GMT
Molecule display, by Christian Guthier
41. Resource-oriented
Design
2. Decide the methods for each
resource
/users /users/{username} /content /content/{ID}
GET GET GET GET
POST PUT POST PUT
DELETE DELETE
Before we had CAD, we had Lead!, by Wendell
42. Resource-oriented
Design
3. Link your resources
Users own content
Each user owns multiple content items
Each content item has one owner
Before we had CAD, we had Lead!, by Wendell
43. Resource-oriented
Design
4. Determine your data schemas
User Content
id id
username owner
firstname title
lastname file/content
Before we had CAD, we had Lead!, by Wendell
Is REST about so-called “pretty” URLs?
Tom Coates, who apparently made this statement at a “Future of Web Apps” summit.
If you want to be real cool, take a pic of yourself doing this and post it to Flickr with the tag “webdevgangsign.”
Or not RPC (remote procedure call)?
* Representational State Transfer
* Term originated in 2000 in Roy Fielding’s doctoral dissertation about the Web entitled “Architectural Styles and the Design of Network-based Software Architectures”
* Not an architecture or a standard for developing web services
* Not a particular format or pattern
* It is a set of design principles
There are six major constraints that define the REST architectural style.
There are six major constraints that define the REST architectural style.
There are six major constraints that define the REST architectural style.
There are six major constraints that define the REST architectural style.
The client-server relationship provides for a separation of concerns. This separation is very important to REST. IMO, it’s perhaps the most important constraint. We’re all-too-familiar with the client-server relationship, since it’s how the Web works, but it’s also what makes the other REST constraints possible and beneficial.
What is a resource?
From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”
All resources share a uniform interface for the transfer of state between client and resource, consisting of
- A constrained set of well-defined operations
- A constrained set of content types, optionally supporting code on demand
What is a resource?
From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”
All resources share a uniform interface for the transfer of state between client and resource, consisting of
- A constrained set of well-defined operations
- A constrained set of content types, optionally supporting code on demand
What is a resource?
From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”
All resources share a uniform interface for the transfer of state between client and resource, consisting of
- A constrained set of well-defined operations
- A constrained set of content types, optionally supporting code on demand
What is a resource?
From RFC 2396: “A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., ‘today’s weather report for Los Angeles’), and a collection of other resources. Not all resources are network ‘retrievable’; e.g., human beings, corporations, and bound books in a library can also be considered resources.”
All resources share a uniform interface for the transfer of state between client and resource, consisting of
- A constrained set of well-defined operations
- A constrained set of content types, optionally supporting code on demand
Advocates claim that REST:
* Provides improved response time and reduced server load due to its support for the caching of representations
* Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
* Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
* Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
* Provides equivalent functionality when compared to alternative approaches to communication
* Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
* Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
- The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
- The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.
One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
Advocates claim that REST:
* Provides improved response time and reduced server load due to its support for the caching of representations
* Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
* Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
* Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
* Provides equivalent functionality when compared to alternative approaches to communication
* Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
* Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
- The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
- The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.
One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
Advocates claim that REST:
* Provides improved response time and reduced server load due to its support for the caching of representations
* Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
* Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
* Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
* Provides equivalent functionality when compared to alternative approaches to communication
* Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
* Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
- The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
- The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.
One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
Advocates claim that REST:
* Provides improved response time and reduced server load due to its support for the caching of representations
* Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
* Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
* Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
* Provides equivalent functionality when compared to alternative approaches to communication
* Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
* Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
- The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
- The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.
One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
Advocates claim that REST:
* Provides improved response time and reduced server load due to its support for the caching of representations
* Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
* Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
* Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
* Provides equivalent functionality when compared to alternative approaches to communication
* Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
* Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
- The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
- The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.
One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
Advocates claim that REST:
* Provides improved response time and reduced server load due to its support for the caching of representations
* Improves server scalability by reducing the need to maintain session state. This means that different servers can be used to handle different requests in a session
* Requires less client-side software to be written than other approaches, because a single browser can access any application and any resource
* Depends less on vendor software and mechanisms which layer additional messaging frameworks on top of HTTP
* Provides equivalent functionality when compared to alternative approaches to communication
* Does not require a separate resource discovery mechanism, due to the use of hyperlinks in representations
* Provides better long-term compatibility and evolvability characteristics than RPC. This is due to:
- The capability of document types such as HTML to evolve without breaking backwards- or forwards-compatibility
- The ability of resources to add support for new content types as they are defined without dropping or reducing support for older content types.
One benefit that's obvious with regards to web based applications is that a ReSTful implementation allows a user to bookmark specific \"queries\" (or requests) and allows those to be conveyed to others across e-mail, instant messages, or to be injected into wikis, etc. Thus this \"representation\" of a path or entry point into an application state becomes highly portable
Humans live in the world of representations. Representation, as a concept, is an attempt (arguably futile) to reach certain acceptable level of objectivity.
For example, if a person wants to buy a house, that person needs to qualify for a mortgage. If that person explains to the mortgage broker that he has $50,000.00 cash available for the down payment toward purchasing the house, the broker will not go ahead and approve the mortgage, even though the quoted amount would be fully satisfactory. What the mortgage broker needs is a more objective argument that would reassure the issuer that the party asking for the mortgage does indeed have enough money for the down payment.
But how is the issuer to go about obtaining the more objective proof? Certainly not by going directly into the applicant's safety vault and counting the money deposited there. Instead, the issuer is simply expecting to receive a representation of that person's balance in his bank account.
That representation projects a sufficient illusion of objectivity, so that the involved parties could sufficiently relax and that the business transaction can eventually take place.
In the same manner, any transaction that transpires on the web is based on the similar representational logic. The actual resource is never being touched. Instead, various representations of the said resource are being prepared, rendered, and shipped to the clients for consumption. Same as in the real world, where the mortgage issuer will never actually touch client's money, but will instead be satisfied with a mere piece of paper representing the balance, resources on the web never get to be directly manipulated by the clients.
URIs uniquely address resources
HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface
All transactions are atomic
HTTP provides cache control
HTTP provides layering
URIs uniquely address resources
HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface
All transactions are atomic
HTTP provides cache control
HTTP provides layering
URIs uniquely address resources
HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface
All transactions are atomic
HTTP provides cache control
HTTP provides layering
URIs uniquely address resources
HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface
All transactions are atomic
HTTP provides cache control
HTTP provides layering
URIs uniquely address resources
HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface
All transactions are atomic
HTTP provides cache control
HTTP provides layering
URIs uniquely address resources
HTTP methods (GET, POST, PUT, DELETE) and content types (text/html, text/plain, etc.) provide a constrained interface
All transactions are atomic
HTTP provides cache control
HTTP provides layering