The REST Triangle (61M)
One way to look at the REST architectural principles is as a means to provide a scalable distributed software system through good caching. Another way is to see REST as an Informatics discipline. (61N)
The authors of any two particular pieces of software need to agree on a lot of things before their creations can start communicating. Many communication frameworks attempt to achieve agreement by providing solutions to all of the different aspects of communication in one coordinated package. These toolkits have so far achieved only limited lifetimes as the needs of users and applications have changed. (61O)
REST is a tool for enabling communication by separating concerns. REST separates the different aspects software components need to agree on into separate problem domains. Each problem domain is decoupled from the others in such a way as it can be solved separately. The main problem domains identified in REST are the nouns, the verbs, and the content-type spaces. Essentially the things that exist, the things you can do to them, and the information you can transfer as part of any particular operation. (61P)
Nouns (61Q)
Nouns are the names of resources. This problem space does not interfere with the verb problem space. The set of operations permitted on a resource can vary independently of the set of resources out there. It does not interfere with the content-type space: So long as the minimum information required or provided by the resource is met, any content type can be used to convey the information. In REST, the same resource can even exchange several different content types. (61R)
Clients treat nouns as opaque. Although nouns contain structured data, clients are not required to interpret that data. Doing so would cross nouns over into the content type space (see UrlConstruction and RestAndURIOpacity?). Even to allow the client to construct one noun from another is forbidden in some forms of REST - but not all (see OpacityMythsReconsidered?, OpacityMythsReconsideredReconsidered?, OpacityForTheStupid). (686)
Be wary also of nouns that contain verbs. http://example.com/addToList is not a good noun, as it crosses into the verb space (in REST it could only be used to document the function or provide the source code, since to the compiler or integrator "addToList?" is a noun). (684)
To actually perform the function, is better to POST to http://example.com/list/tail. Nouns are essentially messages from the server to itself, selecting a particular piece of server-side application state. Nouns must follow a number of principles to work in REST model, though BetterURIAxioms have been proposed and variants proposed for SociosemanticWeb? applications with political design factors. (61S)
The opacity of the noun-space to clients allows servers to organise resources in whatever way they see fit, independently of the organisation other service providers may choose. This freedom in noun selection requires no global agreement, however there is still a social aspect to the noun-space. Clients must still choose your service or your resource over your competitor's resource. You still need to evangelise the benefits you provide. This social problem is very different from the problems in the verb and content-type spaces. (61T)
The URL is currently the best available technology for naming resources in a way that permits communication with those resources. It is hard to see how the URL might be supplanted given the momentum that now exists around it, however REST is agnostic as to whether it is based on URLs or not. The same solutions to the verb and content-type problem spaces can be applied in combination with another identifier scheme. REST allows for innovation in the identifier technology space without interfering with the other problem domains. (62A)
Verbs (61U)
Verbs are the operations that can be applied to resources. In good REST practice, these are a highly-constrained space. See MinimumMethods. (61V)
Verbs are not meant to convey any transferred information, or cross-over into the noun-space. Verbs such as getTime() should automatically set off alarm bells. Allowing this kind of half-noun/half-verb muddies the waters between the problem domains REST is allowing you to address separately. The typical REST verbs are GET, PUT, POST and DELETE. These are used in a very specific minimum way in good REST practice. Other HTTP verbs like REDIRECT are also used where appropriate. (61W)
The verb problem space can be solved by global agreement based solely on generic technical merit. Because it is decoupled from the marketing-style social battle of the noun-space and the schema-intensive social battle of the content-type-space, this battle can be won on its own. (61X)
The specific uses of GET, PUT, POST, and DELETE are now fairly well-entrenched as the best technology for the verb problem space. REST is, however, agnostic about the specific verbs being used. The same solutions to the noun-space and content-type-space apply whichever verbs are used. REST allows for innovation in the verb space without interfering with the other problem domains. (62B)
It also allows for user interfaces to use the verbs directly, see HowWikiComparesToRest. (685)
Content Types (61Y)
Content-Types define information that can be conveyed from machine to machine. HTML defines document structure information, as well as freeform text. A machine can understand the document structure, but meaningfully interpreting the text is currently still a job for a human. (61Z)
Content-Types don't cross over with the noun-space or the verb-space. If you see content that tries to control the processing of the document, your REST alarm bells should go off. Your document should be equally relevant to a GET, PUT, or POST. It should be neutral towards how it is being used, and to whom it is being transferred. The job of content is to convey information. (620)
Content is probably the hardest social battleground to win in effective machine-to-machine communication. The content type must cover at least the common information schema that client and server need to convey to each other. This can only occur as a grass-roots standardisation process that solves specific problems on the ground before being formalised, merged, and resolved by committee. (621)
The right technology for content is still open for active debate, with some of the current front-runners being particular XML format definitions or particular RDF ontologies. REST's view on this and other battles is neutral: Solve this problem in isolation from the verb and noun arguments. Let's take the victories we have already won there, and build upon them here. (622)
Underlying Technologies (623)
Fielding describes REST not as an architecture, but as an architectural style. It may be obvious to you today to use DNS for name resolution, HTTP/TCP/IPv4? as your communications protocol, along with other Internet technologies. Tomorrow you might come up with a slightly different set. (624)
REST decouples the underlying technologies from the other problem domains. This problem can also be solved separately. The decoupling is not quite as neat as between the corners of the REST Triangle proper. If you used a different identifier scheme, HTTP and DNS might not work for you. If you chose different verbs or content-types you may run into problems with firewalls that don't speak your new language. On the whole, however, innovation is accomodated very nicely within the existing best practice technology set. (625)
Conclusion (626)
From the informatics perspective, REST is about solving one social problem at a time using the best possible technology for each. It separates the problems requiring global consensus from the ones you can solve within your own organisation. It separates the problems that require a competative marketing war to be waged from those that require agreement between yourself and your competitors. It separates the general information theory behind REST from any particular technology base. (627)
Best REST practice is evolving and will continue to evolve. Technologies that couple the solutions to these different problems together are likely to fail, as the creaky solution to one problem domain forces the abandonment of the whole communications framework. REST decouples, retains, and salvages the technologies that work. Technologies that don't work are quietly discarded and safely ignored. (628)