REST -What It’s Good For (Part 1: HTTP Caching)

rest-api-logoSo I already covered some of the misconceptions around REST in my previous post (if you haven’t read it, please do), but I want to delve into some of the advantages of using such a methodology. This pattern assumes a simple point-to-point, client/server, request/response architecture, which is far from the only way to skin a cat out in IT land, but if it fits your app, REST can give you certain benefits. Today I will focus on HTTP Caching.

The thing to remember is that REST is designed to work ‘natively’ around HTTP, therefore you can leverage all the functionality of HTTP without any additional cost. Remember, there is a massive ecosystem of web technologies geared around HTTP, and that developers are very familiar with it; by using REST you architecture will fit seamlessly around these existing technologies, and the culture, knowledge and expectations that come with them.

Caching

First of all, remember how I said that a truly RESTful service is one that transmits and represents application state using document objects

{ "order": { "type": "latte", "extrashot": "hellyeah", "status": "in progress"}}

This means that standard HTTP caching can be applied, particularly to GET methods where freshness of data isn’t an issue. This is because to the HTTP server, your object is just another web document to be served up. In our above example, the client might be repeatedly calling ‘GET’ for the above object to check on the status of coffee, overwhelming our server (it’s a very small server powered by a hamster on a wheel, OK?). Assuming that we’re ok with the client waiting up to 30 seconds for up to date information about their coffee (again, bear with me with this), we can simply add a standard HTTP Cache-Control header to the response:

Cache-Control: max-age=30

The beauty of this is that this is all standard HTTP, and so therefore you can use existing your HTTP infrastructure and knowledge to implement it.  By adding a simple header to your response, you’ll both the strain on your app and the impact of repeated polling on your network (assuming you cache via a reverse proxy up front).

“Ah!”, I hear you say, “but let’s suppose you don’t have a RESTful service, and are instead calling a /status/ method over HTTP (RPC over HTTP). You could still use a Cache-Control header to implement caching of the status”

Very true, but suppose you wanted something a little more advanced when it comes to caching. Say, for example, you were using Etags (an Etag is just a hash representation of an object; when an object’s semantics changes, so does it’s Etag). Typically with web documents, the client (such as a browser) will store the Etag of the document as well as the data itself. Then, when it re-requests the page, it sends the original Etag; the server compares this to the documents current Etag, and if it’s different it send the new version over to the client, otherwise it tells the client to re-use it’s existing local copy.

You could see how this could be applied to our hamster-powered, non-urgent coffee solution, can’t you?

Again, you get all this functionality for free; no knowledge, software or infrastructure outside of HTTP is needed to implement this feature for your API. Because with REST, all your apps state is handled via representational web documents, so you get all the functionality HTTP servers have built into them already.

Could you imagine trying to implement something like this using SOAP, or XML-RPC? Not impossible by any means, but it would require custom code, and brittle semantics.

Which brings me nicely onto my next post…..

Advertisements

One thought on “REST -What It’s Good For (Part 1: HTTP Caching)

  1. Pingback: REST -What It’s Good For (Part 2: Semantics and Information Sharing) | Javantis

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s