Synthetic Biology:Semantic web ontology/REST

From OpenWetWare

< Synthetic Biology:Semantic web ontology
Revision as of 20:02, 23 July 2008 by Ilya (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

REST stands for Representation State Transfer, and suggests that what the Web got right is having a small, global set of verbs (GET, POST, PUT, HEAD, etc) applied to a potentially infinite set of nouns (URIs).

  • Interface genericity
in REST each distributed software component exposes the same interface (or at least the same minimal interface).
  • the following rules of thumb can be extracted:
    • when retrieving information without changing the state at the server, use GET
    • when explicitly setting some piece of state on the server, use PUT
    • for pretty much everything else that changes state at the server in a loosely coupled way, use POST
    • for other operations that change state on the server in an early-bound manner (i.e. the client needs to know explicitly what is happening), define a new HTTP method (ok, so this isn't derived from any of the examples - sue me)
There is a profile of SOAP that supports transferring the state of a resource using only the limited actions of HTTP or some other protocols -- that profile is RESTful. Other uses of SOAP carry "actions" to be performed in the SOAP header, regardless of the protocol used -- those would not be RESTful.
All REST interactions are stateless. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it. This restriction accomplishes four functions: 1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability; 2) it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics; 3) it allows an intermediary to view and understand a request in isolation, which may be necessary when services are dynamically rearranged; and, 4) it forces all of the information that might factor into the reusability of a cached response to be present in each request.
The definition of resource in REST is based on a simple premise: identifiers should change as infrequently as possible.
So when we started working on the design for a large image distribution and processing system, we already had a simple and scalable design, and the tools to support it. Just send XML documents representing objects back and forth over HTTP, and use the lightweight DOM structure to hold parsed versions of them inside the application. Add some glue code to let application code access the DOM structures as ordinary Python objects, and you have a complete and scalable system.
Personal tools