Grokking the REST Architectural Style
by Ben Ramsey
- 8,691 views
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 ...
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.
Statistics
- Likes
- 20
- Downloads
- 277
- Comments
- 1
- Embed Views
- Views on SlideShare
- 7,951
- Total Views
- 8,691
Michael2008S
1–1 of 1 previous next
Tom Coates, who apparently made this statement at a “Future of Web Apps” summit.
* 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
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
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
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
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
* 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
* 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
* 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
* 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
* 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
* 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
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.
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
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
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
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
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
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