REST is an architectural style for building large-scale networked applications. It is a description of the features of the WWW that made the Web so successful. (2E3)
REST describes a networked system in terms of (2E4)
- data elements (resource, resource identifier, representation) (2E5)
- connectors (client, server, cache, resolver, tunnel) (2E6)
- components (origin server, gateway, proxy, user agent) (2E7)
Aspects of REST (2E8)
- Data elements are accessed through a standardized interface. (2E9)
- Components communicate by transferring representations of resources through this interface rather than operating directly upon the resource itself. (2EA)
- Connectors present an abstract interface for component communication, hiding the implementation details of communication mechanisms. (2EB)
- Components use connectors to access, provide access or mediate access to resources. (2EC)
- All requests made to connectors must contain all the information necessary for the understanding of that request without depending on any previous request, i.e. they are stateless. (2ED)
Since REST is an extracted description of the WWW, it is no surprise that the protocol that exhibits the most number of these aspects is HTTP. However, REST and HTTP are separate concepts - it is entirely possible to apply REST concepts to other protocols and systems. In line with WebBestPractice? observed in many protocols, including especially the GFDLcorpus, some consider GenerativeNaming and UriStability? to be fundamental. That is, concepts like TimePlacePerson that do not change, should be represented in a very stable way, typically an OpenContent? name scheme such as the GFDLCorpusNamespace (what [Wikipedia] uses and translates). ASimpleIdeologyOfWikitax and StandardWikiURI present this noun-centric view in some detail, as do OpacityReconsidered and OpacityForTheStupid. BetterUriAxioms based on all this "RESTHeresy" are being created. This is one the basic activities of ThisWiki. (5QH)
Whether one views REST as applying just to verbs (the classic view) or also nouns (the heresy), it is important that intermediaries are an explicit aspect of the architecture and because of REST's characteristics, these intermediaries can be more than just dumb routers, they can be active participants. This becomes extremely important when considering pronouns, e.g. statements about "this" or [We] or "you", which change meaning based on the host or server which present them. Statements of commitment, such as a ReflexiveImperative? ("this wiki must...") are very sensitive but also very powerful as they open the possibility of redefining the verbs, nouns and pronouns from within the namespace using only the online transactions. (2EE)
However, most people see the immediate value of components and connectors, and see the deeper concepts as challenging. An InformationArchitect? is not usually trying to challenge the PowerStructure? of the organization (as the pronoun view does) nor go beyond a WeakOntology? to try to name everything that might appear in any URI, period. Most REST discussion thus focuses on the verbs and 'information architecture' aspects of REST - resources, representations, URIs, standardized interfaces, etc. This area is informally known as 'resource modeling'. Most examples are framed in HTTP messages and URI addressable resources. The theory is that many complex systems can be fully described and implemented with just pure HTTP. (2EG)
Aspects of ResourceModeling (2EH)
ResourceModeling focuses on the data elements of the REST architectural style. It considers these aspects of REST: (2EI)
- addressable resources (2EJ)
- uniform interfaces that apply to all resources (2EK)
- stateless messages (2EL)
- 'representations' - multiple content types accepted or sent (2EM)
- dealing with processes as resources, e.g. LindaAndTheWeb (5QI)
- dealing with long term persistent resources with shared slowly changing names, e.g. ASimpleIdeologyOfWikitax (5QJ)
ResourceModeling is the process of organizing a distributed application into URI addressable resources that provide the full capabilities of that application through the use of only standard HTTP messages : GET, PUT, POST and DELETE. (2EN)