I have a theory that important ideas in computing don't get that extra kick into the working programmer consciousness until they have a cool name acronym. Ajax, SOAP and REST come to mind as recent examples.
The way REST came to widespread use in the computing world is unusual. The term appears to have been coined by Roy Fielding in his 2000 PhD dissertation for the University of California, Irvine. Note that Fielding is hardly an outsider, he helped create the HTTP 1.0 specification that has provided the basic rules for the Web since 1996. His experiences with the evolving Web standards provided the background for the dissertation.
Fielding points out that the World Wide Web works best when using the style he calls Representational State Transfer or REST. Think of REST this way – when a browser gets and displays the elements which make up an HTML page, it is getting a representation of the current state of that resource. Fielding's dissertation enumerates the constraints of the REST style and explains why they are essential to the best current Web practice. He also includes some discussion of the "mismatches" between REST and certain current Web practices and how they lead to bad design.
Fielding feels that using HTTP to piggyback application protocols through firewalls the way XML-RPC and SOAP do is a "fundamentally misguided idea." It defeats the idea of having a firewall and results in firewall vendors having to detect the piggybacked protocol in order to protect the system. Since most SOAP applications use HTTP for exactly that purpose, you can see where the conflict between REST and SOAP got started. Fielding feels that if you are going to use HTTP, it should be with HTTP semantics.
The REST style emphasizes that interactions between clients and services is enhanced by having a limited number of operations or "verbs" and a standard interface between components, namely that provided by the HTTP protocol. Flexibility is ...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
provided by assigning each resource its own URI, essentially giving you an unlimited number of "Nouns." By giving exact meaning to the HTTP verbs of GET, POST, PUT and DELETE, REST avoids ambiguity. For example, GET is not allowed to create any side effect but simply returns a resource representation.
In the early days of the Web, as people were experimenting with putting together Web applications by collecting elements from various sources, there were plenty of examples of informal precursors to Web services that parsed information out of HTML pages and used it for purposes the originators did not intend. This Web analogy of "screen scraping" shows that REST style approach predates more complex Web services.
REST is a style not a standard
You might think of architectural style for software as being one step of abstraction above design patterns. However, according to Fielding, a collection of design patterns is not the same as an architectural style because patterns are too close to particular problems.
Since REST is a style for hypertext systems rather than Web services, the title "REST versus SOAP" is somewhat misleading. However, many software designers contemplating creating a Web service have come to the conclusion that SOAP is overly complicated and a simpler REST-like design is preferable.
Contrasting REST with RPC style
The architecture of remote procedure calls as embodied in Web services based on XML-RPC or RPC-style SOAP has a completely different style. The client commands the service to carry out a particular operation. In other words, RPC has a verb orientation.
REST emphasizes resources (think nouns) with a uniform interface for addressing them, while RPC emphasizes processes (think verbs) with a uniform interface for invoking them. With a RPC-based architecture, there is no limit to the number of verbs. REST says we can get by with only four, the familiar GET, POST, PUT and DELETE of the HTTP standard, and make the resource addressing handle the variability.
A simple REST example
Suppose we want a Web service exposing a part catalog from which users will be able to get part description, pictures, installation instructions and so forth. In order to get a description for a part number "n1996-01." The user would format a GET request similar to this URL:
http://company.com/catalog/description/n1996-01
In handling this request the "/catalog" would map to a service, but the "description/n1996-01" would be interpreted by the service to locate the resource. In creating the response, the service would use the Content-Type header to specify the format being returned. In this case, presumably it is HTML or XML which the client would use to control the disposition of the representation.
A request to get a picture would address "/catalog/picture/n1996-01" and the response would give the image Content-Type.
Commercial use of REST
Many of the Web's commercial enterprises have become aware of the interest in REST in recent years. The Google Data API (currently still in beta) provides a simple protocol specifically using REST principles. HTTP GET requests to the service result in XML formatted data in either the Atom or RSS syndication format. Google is also working on a publishing protocol using Atom and the POST, PUT and DELETE operations. The eBay service provides for accessing services using a variety of language tools, including document/literal style SOAP and REST style.
Can the REST style ever be a complete replacement for the RPC style of XML-RPC and SOAP? I certainly don't think so and in the next article I will try to suggest the areas where SOAP reigns supreme.
Resources
Roy Fielding's dissertation
The Wikipedia article contains a list of well known services that provide REST style developer interfaces.
Here's a thoughtful article on REST and another one.
Google's Data APIs (Beta) Developer's Guide
Documentation on eBay's REST API
