Last modified


This wiki is dedicated to everything REST & WOA.

In a Nutshell

In REST there are no objects or methods.  Instead, everything is a resource. Sometimes REST is also referred to as “resource-orientation.”  REST is designed to leverage intermediaries, which participate in the exchange.  By giving intermediaries more insight into the exchange, they can respond on behalf of the resource, short-circuiting communication and offloading the resource server.  For example in WOA, an application of REST to the Web, these intermediaries are corporate proxies or content delivery networks, such as Akamai.  REST also requires decoupling of knowledge between the resource and the agent acting upon it.  This separation of concerns is achieved by having a semantically rich representation to describe to the agent how it can act upon the resource and discover other resources.  For example in WOA, common representations are (X)HTML, Atom, and RDF.

In a RESTful system, an agent communicates with a resource using its location, a verb that describes the operation, and a representation of the desired state.  The resource location must be universally comprehensible and describe at most one resource.  In WOA, the location is a URI.  Intermediaries use the location to route the message, but also to determine if a cached response already exists.  This step would not be possible if the intermediary could not identify with certainty the resource in question.  Similarly, the operation verb is taken from a known vocabulary.  The verb tells intermediaries the nature of the exchange and if it invalidates existing information about the resource.  The verb does not tell what the effect of the exchange will be, only that there might be one, if any.  In WOA, the verbs correspond to the HTTP methods GET, POST, PUT and DELETE.

The representation of the resource must instruct the agent how it can act upon the resource.  For example in WOA, HTML <form> elements are used to describe how new requests are constructed, what parameters to submit, and where to submit them to.  This enables the resource author to modify the set of parameters, how they are embedded into a request, or where they are sent to without requiring a change in the agent.  This level of decoupling enables independent evolution of agent and resource while maintaining compatibility.


While REST is not tied to HTTP, the popularity of HTTP makes it the most common protocol to which REST is applied.  The following pages capture HTTP headers, methods, and status codes as defined by across all RFCs covered by this wiki.


Core to getting the most out of REST is to have a strong understanding of the standards that already exist.  The following RFCs are covered in this wiki.

Misc Articles

Various articles have been contributed by visitors like yourself.  These provide a good insight into the various aspects of RESTful design and associated issues.

Caching Matters
What are the advantages of caching data?  How do you cache data?  And what are the different kinds of available caching strategies?
Code On Demand
Making use of Code on Demand (COD).
Designing URIs This page captures thoughts and ideas on how to design URIs for WOA/RESTful web-services and applications.  Technically, URI design is irrelevant as all URIs should be discovered through request-response exchanges between the user agent and the server.  However, in practice, well designed URIs have been conducive to good architecture.
Resources and Representations
Introduction to the differences between a resource and its representation.
The Hypermedia Scale
When it comes to hypermedia, there are various levels of capabilities.  This article is a first attempt at categorizing hypermedia types according to their expressive power.
Why HTTP Isn't A Transport Protocol
Learn about the real purpose of HTTP.
HTTP i18N Patterns
Patterns for HTTP internationalization.


Page statistics
215657 view(s) and 24 edit(s)
Social share
Share this page?


This page has no custom tags.
This page has no classifications.