I work in a product development group with a software product in use at over 600 companies, which they depend on for their mission critical record keeping. One day, not so long ago, we woke up and the world had changed. No, this was not the financial crisis. It was far more significant for our development team. We discovered that our users’ perception of what was a good application had changed. The ones they liked could browse, mash-up, poke, and prod any number of resources. But our Enterprise Application couldn’t. We were practically selling legacy software.
As we found out, to satisfy a modern Enterprise Application user it is no longer sufficient to transact with a single application based on queries from a single data source. We were spending an increasing amount of time and effort masking the deficiencies of our architecture by creating non-reusable mash-ups within our various user agents, or worse still, some of our clients and development teams were unwittingly limiting scalability by introducing call outs within the resource manager - see Figure 1. Furthermore, because we had multiple user agents each managing their own resource manager connectivity, a single functional change often had to be repeated for each user agent. We needed a change, a change that would allow us to draw information from, and transact with, many sources at the back end, while at the same time be able to rapidly alter the functionality across many channels at the front end.
Figure 1 Enterprise Application mash-ups and callouts
After some deep thought, we decided on a change to our architecture that seemed to satisfy all our requirements. We changed our application from being monolithic, all the code in one place, to one with code in two places. This journey actually started many releases ago and is shown in the diagrams below.
Figure 2 Original Architecture
In a monolithic application, see Figure 2 Original Architecture, the user agent is ‘dumb’ and the session state is held at the resource manager. This is usually done using some kind of scratch pad. One interaction from the user may be multiple calls into the business and data logic to manage the state of the resource.
Figure 3 An early evolution of our architecture
In Figure 3 you can observe an early evolution of our application architecture; some user agents began to separate the user interface logic from the business and data logic. The user interface logic can be defined as the part that depends on the session state. To keep the user’s application up to date, we interact with the resource manager as many times as we need. This change enables features like AJAX.
Figure 4 Current application architecture
By adding the ability to route requests and transform them to our models – as seen in Figure 4, we could now do mash-ups. However, we want to have a uniform model of our application to stop repeating ourselves; where with multiple user agents (one for the desktop, one for mobile, one for touchscreen and so on) can all share a similar interaction.
Figure 5 Interaction architecture
Our latest change, as seen in Figure 5, proposed a new interaction layer that enables us to route requests to resource managers for all the user agents. In MVC (Model View Controller) terms we have put a gateway between the view and controller in the user agent (providing rich interaction) and a model mapped to the resource managers.
Our Flex based Rich Internet Application (RIA), servlet based web applications, mobile Apps, and Interactive Voice Response (IVR) user agents can now be completely decoupled from our various resource managers - in much the same way that a web browser is decoupled from the various websites throughout the world. To accomplish this we use an XML media type over HTTP as the only means of communicating from the user agents to the resource managers and a HATEOAS (Hypertext As The Engine Of Application State) constraint to control the behaviour of all the user agents from the interaction framework – see Figure 6. The interaction frameworks’ other responsibilities include a mash-up and synchronous call-out capability, and the ability to rapidly define new resources to be managed by our user agents.
Figure 6 Interaction layer
Introducing this level of change into a mature Enterprise Application was never going to be an easy task. We quickly decided that the REST (REpresentational State Transfer) architectural style[1] was exactly what we needed; as a way of interacting between the user agents and our interaction framework. The requirement on us, if we are to provide a RESTful resource manager, is to comply with the constraints of the REST architecture style. These are:
- Client Server – we get this by binding to HTTP
- Stateless – we get this by binding to HTTP
- Cache – we get this by binding to HTTP
- Uniform Interface – this is the main subject of this article
- Layered System – we get this by binding to HTTP
- Code on Demand (optional) – this I not discussed in this article
- Representations – this is discussed in the uniform interface section below
- Resources – we get this by binding to HTTP
Our analysis of the RESTful constraints indicated that a crucial constraint for us was the uniform interface. An application binding to HTTP has to comply with the uniform interface on top of its HTTP infrastructure. Our challenge is to make our mature Enterprise Application RESTful and conform to these same constraints.
Our first priority was to identify what ‘things’ could be managed by our application and organise them into resources user agents can navigate and render. Once we had identified what resources could be managed, we needed to establish the links between them and how they would transition state. With more than three and a half thousand individual, or non collection, resources managed by our application, and a staggering mass of relationships, we were going to need something a bit more substantial than a pen and paper.
UML class diagrams proved to be an excellent way to describe our resources and the relationships between them. We used the attribute property to represent the elements of our resources, and the association property to represent the links between the resources – see Figure 7. At runtime these two pieces of information are used by the user agents to render a screen and navigate from one screen to another – in the same fashion that a web browser renders html into a page and links to other pages. With UML diagram in hand we can analyse our resources connections to one another and visualise how we might interact with them; as you can imagine this was incredibly useful during our development phase.
Figure 7 – Simplified resource example
A few recent and frankly excellent pieces of research are emerging that seek to establish techniques for describing application state using State Diagrams and certainly could have helped us during our analysis phase – notably REST: From Research to Practice, Chapter 5, Beyond CRUD (Rauf and Porres 2011) [2] and Formal Modeling of RESTful Systems Using Finite-State Machines (Zuzak, Budiselic and Delac 2011) [3]. We also found State Diagrams useful for modelling our system, but we’re primarily interested in modelling our resource state transitions rather than application state transitions. Our users manage resources according to easily understandable interaction patterns and we have limited need for wizards, or other controlled user interactions, therefore we seemed to have little need for sophisticated HATEOAS modelling in the early stages. However, modelling resource state transition surely saved us many months of pain.
Once we had modelled our resource state transitions and attempted to map these transitions to a uniform interface based on HTTP methods and URIs, some interesting findings started to unfold. As noted earlier, we really only needed to do this for one resource type as all our resources have a uniform lifecycle. In our first attempts to map the transitions to URLs with GET, PUT, POST and DELETE we struggled to produce any sensible RESTful looking URIs, and our attempts to map the transitions to POSTs seemed to be getting away from RESTful principles. In the end we were starting to acknowledge that something didn’t fit – a gap in our knowledge perhaps?
Figure 8 - One of our early Resource State models
If we take a step back for a moment and look at the most popular REST architecture in the world – the World Wide Web – we can note that most interactions are read-only, safe, GET interactions. This might go some way to explaining why we could not find the same depth of research for update based REST interactions as were available for read-only interactions. By way of example, the reference books available at the time often dedicated just a handful of pages to updates, but hundreds of pages to other REST concepts. Furthermore, some of the concrete examples within these books seemed to contradict one another. Could we therefore conclude that no one was using REST to build Enterprise Applications which are predominantly update based or could we conclude that REST is not suitable for use in such a scenario?
The uniform interface constraints are described as follows by (R. Fielding, Representational State Transfer (REST) 2000):
“REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.”
This is not Fielding’s last word on the subject however. In (R. Fielding, Designing a New Protocol for the Web 2002) he adds the following constraint to the list of four above: “Resource-generic interaction semantics”. This is in the context of creating a new Web protocol called Waka, where Fielding creates new methods for manipulating Waka resources which include RENDER and MONITOR.
Let us deal with each of these five constraints in turn.
Identification of Resources
We
use URIs to identify all our resources; being defined by Fielding as any information that can be named, the
number of resources in our system far out-weighs the number of domain objects. Excluding a few well known service roots our
resources are accessible by links from at least one other resource. Although the use of URI templates [5] is still within the
RESTful constraints, no meaning should be derived from our URI structure. To convey meaning about any given resource we
rely on the information within the media type just as Atom does with its link relations [6].
Manipulation of resources through representations
We are in the process of defining our representations, but it is likely we will take an approach similar to OData. The media type to carry
our representation is quite fixed, but the representation of our resources is
continuously changing as the application evolves through both our enhancements
and our customer’s specialisations. To support
this flexible payload requirement we think an Atom based media type with an Entry
that supports a set of property values, as OData Property has done, will be the way forward.
HTTP defines a set of methods for manipulating resources, used by AtomPub and also OData for instance, for manipulating resources. However, we found our individual resources could be uniformly manipulated using a different set of methods, just as Fielding found in Waka. We discuss this in more detail below and this is the main subject of this article.
Self descriptive messages
We
intend to define self-descriptive messages within our XML or JSON based media type with
inline metadata for our representations.
The important point here is not to rely on ‘out of band’ information for
understanding messages. Fielding has
criticised some other projects which define custom http methods, such as WEBDAV
[8], for not being
RESTful as they require out of band knowledge [9]. There has also being criticism [10] of OData for
requiring user agents to construct URIs to the metadata and its failure to
define a media type for the Atom Entry. Both of these criticisms seem justified for
large scale deployment scenarios due to the client-server coupling this
introduces.
Hypermedia as the engine of application state
Usually abbreviated as HATEOAS, this is absolutely crucial for us. The whole point of our interaction framework is to move session state out of the resource manager and in so doing separate session state from resource state. The reason we chose the REST architectural style is because it uses hypermedia to change the state of the user agent (what REST calls application state) and thereby decouples the user agent from the resource manager.
Resource-generic interaction semantics
Although a huge number of systems derive significant value from a RESTful architecture using HTTP GETs alone, many of the same benefits are available for applications that need to manage resources (that is, change their state). In our case we manage a large number of resources and the main benefit is user agent decoupling. However, we can also benefit from other infrastructure optimisations provided we establish very clear interaction definitions or reuse an existing interaction definition such as HTTP’s (Fielding, Hypertext Transfer Protocol -- HTTP/1.1 (9 Method Definitions) [11]). Therein is the key, by establishing a very clear definition of the Uniform Interface any suitably informed user with a RESTful user agent can manage our resources without the user agent having any explicit knowledge of what it is managing.
To determine the right way to transition resource state within our RESTful Enterprise Application we established principles to keep us on track: resources must have a uniform interface; we must not accidentally implement RPC; and we must not rely on out of band information for the user agent to interact with our resources. Following our application analysis and modelling exercise, which revealed that all of our three and a half thousand resources support the same six interactions, we had high hopes of being able to define a suitable uniform interface without too much difficulty. Three main options seemed to present themselves: one that reused HTTP methods GET, PUT, POST, DELETE; one that “overloaded” POST; and a third based on defining custom methods.
As discussed in various REST research papers, the uniform interface constraints give rise to many of the strengths of a RESTful architecture. One aspect of defining, or understanding, our Enterprise Application’s resource-generic interactions was to establish the safe and idempotent characteristics of each operation. This knowledge not only affords many optimisations in the underlying infrastructure, but also provides a user agent implementer with a definition of any explicit guarantees for a given interaction. Our application heavily utilised idempotent operations to ensure consistency of the underlying resource state, a single duplicate transaction could result in a significant loss for our customers, so we were keen to define a uniform interface that elegantly supported this characteristic. As already discussed, HTTP defines a set of methods with well-defined safe and idempotent properties, but the question remained how to best utilise these for our interactions. The options are summarised in Table 1 Uniform Interface Options.
Table 1 Uniform Interface Options
Interaction Description
|
Our Requirement
|
HTTP Method
|
Overloaded POST
|
Custom Method
|
Retrieve
a resource
|
Safe, Idempotent
|
GET
|
GET
|
SEE (GET)
|
Move
a resource from live to history
|
Unsafe, Idempotent
|
PUT
|
POST
|
HISTORY
|
Add
an authorisation to a resource
|
Unsafe, Idempotent
|
PUT
|
POST
|
AUTHORISE
|
Remove
authorisation from a resource
|
Unsafe, Idempotent
|
PUT
|
POST
|
REVERSE
|
Delete
a resource
|
Unsafe, Idempotent
|
DELETE
|
POST
|
DELETE
|
Update
a resource
|
Unsafe, Idempotent
|
PUT
|
POST
|
INPUT (PUT)
|
Create a resource
|
Unsafe
|
POST
|
POST
|
POST
|
Our Enterprise Application has two kinds of resources, as do most: collections and individuals. A collection might be /customers and an individual might be /customers/123. It is the individuals that could accept our custom SHARDI methods. Collections can be treated using HTTP methods, perhaps in future we could use AtomPub as an approach. To create a new individual we POST to the collection, as is normal in REST. However, in our case we POST to the collection to get back a new URI with a unique identifier. This is a resource we can, if necessary, throw away. This makes the inputting of a new resource idempotent and is similar to the approach in "Reliable Delivery inHTTP" [13].
HTTP’s use throughout the World Wide Web is clearly a great example of the success of a uniform interface and if we look more carefully it is also a great example of how infrastructure can support interaction by understanding the characteristics of the HTTP methods. The ability for infrastructure at all levels to cache GET operations is one of the obvious ways we transparently benefit from its well defined safe characteristics. By establishing a standard that makes explicit
guarantees about a given interaction, as HTTP has done, many optimisations in
the underlying infrastructure and user agents become possible. On the whole these standards have been hugely
beneficial to the web, but can of course be ignored and cause havoc as was the case for the Google Web Accelerator [12].
Our Enterprise Application certainly could benefit from an HTTP infrastructure optimised for GET operations, but perhaps less obviously, by understanding which operations are idempotent our interactions can be enhanced by also caching writes. Imagine for a moment that you’ve built an email server with a RESTful interface. An idempotent operation to mark an email as “read” is entirely cacheable. This operation can be retried upon failure, at any time, and the result will still be the same. If we mark a large number of emails as “read” there is also no need to wait for these operations to complete; our users can carry on with other tasks.
You could make a strong case for an interface based on HTTP methods as any RESTful user agent available today would be able use it (although most Web browsers can actually only use POST and GET today). Any agent writer can take an HTTP connection class and start transacting with the resources. Although our primary goal is not to open up our system to any user agent, this is certainly a very attractive feature. Furthermore, an HTTP interface allows us to leverage community knowledge of the HTTP methods, readily reuse available test clients, and of course benefit from any existing HTTP infrastructure.
As already stated, our product already makes extensive use of idempotent operations for managing resources and, when put to use in a REST architecture, this knowledge allows us to safely retry operations without risking unintended consequences. For an interaction based on HTTP, the idempotent operations PUT and DELETE were certainly going to feature quite heavily in our design. The challenge then seemed to be how to create a sensible URI scheme for our resources. In keeping with RESTful principles, recall that a resource is any information that can be named. Put another way, REST is based on nouns and the few methods in our uniform interface are the verbs.
By far the greatest advantage of using HTTP’s
resource-generic interface is that any RESTful user agent available today could
use it. Any user agent developer can
take an HTTP connection class and start transacting with your resources. Furthermore, there is a wealth of community
knowledge for the HTTP methods, readily available test clients, and the
existing HTTP infrastructure has been optimised for them. However, we found that creating suitable
resource state transitions within the RESTful constraints can be difficult to
understand and difficult to implement correctly.
If all resources need to be named, we can easily check the logic of our URI scheme by simply asking ourselves “Is this URI a noun?”, or alternatively “Have we created a URI that is a verb by mistake?”. We are going to create a noun based URI scheme and transition the state of a fictitious Customer resource.
This fictitious example of transitioning a Customer resources’ state is going to require a little imagination. To avoid getting bogged down in our HATEOAS interactions we are only going to show the requests that are needed to transition the resource state and the accompanying response headers. In the real world we are of course going to navigate our way through this resource transition as guided by the server through our chosen media type. To begin, imagine that we have navigated our way to a “GET /customers HTTP/1.1”.
The first representation we see offers us
several choices for managing customer resources; the /customers/new resource provides a way to create new
customers.
Request
POST /customers/new HTTP/1.1
Response
HTTP/1.1 200 OK
...
[body includes a form that can filled out for subsequent PUT /customers/123/unauth]
POST seems to be a good choice here as the operation is neither safe nor idempotent. A POST to the collection resource returns a throw-away-able resource in the form of the next available customer ID (ID 123 in this case). We return an HTTP 200 OK response as the next available ID has been incremented, but nothing has been created at this stage. Once we’ve filled out the form our next interaction with the server is to create the customer content.
Request
PUT /customers/123/unauth HTTP/1.1
Response
HTTP/1.1 201 Created
Location: /customer/123/unauth
...
At this point we have now created a Customer. However, you might have noticed that the server instructed us to PUT our Customer to an unauthorised version of the customer. In our application, every resource creation or modification should be authorised by at least one other individual. To perform this authorisation we provide an authorised user the ability to add their authorisation to a resource.
Request
PUT /customers/123/unauth/authorisers/Bob HTTP/1.1
Response
HTTP/1.1 201 Created
Bob has now authorised this new Customer. PUT is a good choice here as Bob could PUT his authorisation on this resource any number of times, but logically he can only be added as an authoriser once. This particular resource actually requires two authorisers; it will need a second approval from Bob’s manager Louisa. Louisa has a reputation for being on the ball and has spotted a problem - this Customer already exists. At this point Louisa decides it is best to remove the duplicate Customer and inform our unwitting data entry clerk of their mistake.
Request
DELETE /customers/123/unauth HTTP/1.1
Response
HTTP/1.1 202 Accepted
Louisa’s action has marked the Customer for deletion in this evening’s overnight run as indicated by the 202 Accepted response. Again, DELETE can be performed any number of times, but it is still only possible to be flagged for deletion once. Another manager who wasn’t so on the ball and wasn’t aware of the duplicate Customer might have added their authorisation with the following request:
Request
PUT /customers/123/unauth/authorisers/Nick HTTP/1.1
Response
HTTP/1.1 303 See Other
Location: /customers/123
This example shows that we can perform our SHARDI interactions using standard HTTP methods as can also be seen in Figure 9 State Machine Diagram SHARDI-HTTP. By using a combination the URIs we return in the representation of our resources and the allowed methods for those resources. The complete mapping of SHARDI to HTTP is shown in Table 1 Uniform Interface Options on page 7 above.
Figure
9 State Machine Diagram SHARDI-HTTP
An alternative to mapping our methods to HTTP methods is to use POST for all the operations that are not safe, indicating somewhere in the URI what the operation is, either with query parameters in your URI, by defining the URI in a verb like way or using some other element which breaks our principle of not using remote procedure calls in our URIs. In addition to breaking that constraint, we are now unable to tell the infrastructure if our operation is idempotent and so lose the advantages of being able to retry these operations.
Many resource interfaces that claim to be RESTful break this constraint, as the difference between a PUT to a noun and an POST to a URI with the verb is quite subtle and we’re happy to admit to that we have created interfaces in the past that required user agents to POST to URIs along the lines of /myresource?action=doStuff. Someone has even given this technique a name -“overloaded” POST [14], but this is not how we want to build our uniform interface as it breaks the principle of avoiding remote procedure calls in our resource interface.
Another alternative to mapping our SHARDI methods to HTTP methods is to provide a new resource-generic interface for our resources which explicitly uses the methods SEE, HISTORY, AUTHORISE, REVERSE, DELETE and INPUT (SHARDI). Three of these can actually be replaced directly with the equivalent HTTP method as SEE has the same meaning as GET, INPUT as PUT and DELETE as DELETE. That leaves just three methods for our new generic interface HISTORY, AUTHORISE and REVERSE. In each case these create a new resource. In the case of AUTHORISE, a new live resource is created. In the case of HISTORY, an archived version is created. In the case of REVERSE a new unauthorised resource is created. However, just as in the case of INPUT, which is idempotent because we already know the unique identifier of the resource, these are idempotent methods.
There is a precedent for adding methods to HTTP interactions. This is what WEBDAV has done in its use of HTTP and what Fielding intends to do with Waka. WEBDAV added methods for manipulating folders and files which includes PROPFIND, MOVE and COPY. Fielding has criticised WEBDAV, and specifically PROPFIND, for not being RESTful by breaking the constraint that every resource should be addressable by a URI. However, we think it is possible and sometimes desirable to introduce new methods in an HTTP exchange provided we don’t break the RESTful constraints.
In particular we need to ensure that a SHARDI user agent can discover which resources allow the SHARDI methods without requiring out of band information. This is crucial as we want to design for the long term, so that a user agent written today can work with resource managers delivered tomorrow and vice versa. We intend to achieve this by using the HTTP Allow header to communicate the valid next state transitions for a resource and furthermore we aim to allow the client to request a resource state transition, but we’ll make no guarantees this transition will occur as per the HTTP specification for Allow. We will however advise what transitions are allowed when asked to do so via OPTIONS, and return 405 Method Not Allowed like a good citizen when a transition is not valid.
This is how the same interaction from option 1 would look with our SHARDI Customer resource-generic interface:
The first representation that we see will still offer us several choices for managing customer resources and one choice will allow us to create new customers. This is the /customers/new resource.
Request
POST /customers/new HTTP/1.1
Response
HTTP/1.1 200 OK
...
[body includes a form that can filled out for subsequent PUT /customers/123/unauth]
No change here, POST still seems like the best choice as the operation is neither safe nor idempotent. Once we’ve filled out the form our next interaction with the server is to create the customer.
Request
INPUT /customers/123 HTTP/1.1
Response
HTTP/1.1 201 Created
Allow: GET, HEAD, INPUT, AUTHORISE, DELETE
...
At this point we have now created a Customer. However, you might have noticed that the server has advised us that we can now attempt to AUTHORISE this resource. To perform this authorisation we need to be an authorised user, but this request may result in 405 Method Not Allowed if someone else has already authorised this resource.
Request
AUTHORISE /customers/123 HTTP/1.1
Response
HTTP/1.1 200 OK
Allow: GET, HEAD, INPUT, AUTHORISE, DELETE
Bob has now authorised this new Customer. AUTHORISE is an idempotent operation and as such Bob could AUTHORISE this resource any number of times, but assured that this authorisation will only occur once. From the Allow header we can tell that this resource needs another authoriser; it will need a second approval from Bob’s manager Louisa. There is no change to the DELETE interaction and Louisa still needs to inform our data entry clerk of their mistake.
Request
DELETE /customers/123/unauth HTTP/1.1
Response
HTTP/1.1 202 Accepted
We now know Nick is not as on the ball as Louisa and he simply authorises in the same fashion as Bob.
Request
AUTHORISE /customers/123 HTTP/1.1
Response
HTTP/1.1 200 OK
Allow: GET, HEAD, INPUT, HISTORY
This example shows that we can perform our SHARDI interactions using custom HTTP methods as can also be seen in Figure 10 State Machine Diagram SHARDI-Custom. Using a combination of custom http methods and the Allow header we have established a resource-generic interface semantic that is much easier to negotiate than our HTTP equivalent, plus we have not strayed from the RESTful constraints at any point. The complete mapping of SHARDI to Custom methods is shown in Table 1 Uniform Interface Options on page 7 above.
Figure 10 State Machine Diagram SHARDI-Custom
I've made an attempt to discuss three options to transition resource state,
but there are certainly plenty more e.g. the use of custom link relations. When searching for alternatives my main aim would be to simplify the communication of resource state change options and a mechanism that provides a self-descriptive
nature that could inform the infrastructure of our interaction semantics.
Enterprise Applications like ours have a legacy of
user interaction issues caused by tight coupling of the client to the server. We think REST is our vehicle to achieve
openness, innovation at user interaction, and web scale. In a structured, constrained, and regulated
environment of predominately record keeping activities a resource-generic
interface such as SHARDI could allow us to greatly simplify resource state
transition. However, the HTTP resource-generic
interface is more suitable because of the user agents, tooling, and
infrastructure already built on this standard.
Creating self-describing resource-generic interfaces could simplify resource
state transition and provide opportunities to optimize unsafe, idempotent
operations within external apps and infrastructure.
[1] R. Fielding, "Representational State Transfer
(REST)," 2000. [Online]. Available: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.
|
[2] I. Rauf and I. Porres, "Beyond CRUD," in REST:
From Research to Practice, 2011.
|
[3] I. Zuzak, I. Budiselic and G. Delac, "Formal Modeling
of RESTful Systems Using Finite-State Machines," 2011. [Online]. Available:
http://www.springerlink.com/content/j233175h2q3h7631/.
|
[4] R. Fielding, "Designing a New Protocol for the
Web," 2002. [Online]. Available:
http://www.gbiv.com/protocols/waka/200211_fielding_apachecon.ppt. [Accessed
2011].
|
[5] J. Gregorio, "IETF URI Templates," 2007.
[Online]. Available:
http://tools.ietf.org/html/draft-gregorio-uritemplate-08.
|
[6] M. Nottingham, "The Atom Syndication Format,"
2005. [Online]. Available: http://www.ietf.org/rfc/rfc4287.
|
[7] OData, "OData," circa 2008. [Online]. Available:
http://www.odata.org/.
|
[8] E. L. Dusseault, "WEBDAV," [Online]. Available:
http://www.ietf.org/rfc/rfc4918.txt.
|
[9] R. Fielding, "No REST in CMIS," 29 09 2008.
[Online]. Available: http://roy.gbiv.com/untangled/2008/no-rest-in-cmis.
|
[10] D. Miller, "Oh Data," 2009. [Online]. Available:
http://www.bizcoder.com/index.php/2009/11/30/oh-data/.
|
[11] R. Fielding, "Hypertext Transfer Protocol -- HTTP/1.1
(9 Method Definitions)," June 1999. [Online]. Available:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html.
|
[12] "Google Web Accelerator," [Online]. Available:
http://37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php.
|
[13] P. Prescod, "Reliable Delivery in HTTP,"
[Online]. Available: http://www.prescod.net/reliable_http.html. [Accessed 11
October 2011].
|
[14] "Overloaded Post," [Online]. Available:
http://blog.robustsoftware.co.uk/2009/07/post-overload-implementation.html.
|
