Does REST really mimic the web?

REST extends this distinction to mean that PUT always associates the specified URL with the created or updated entity but POST creates a new URL if required and returns it as the result.

But and this is an important but - the advocates of strict REST claim that GET, DELETE, POST and PUT are the four verbs you must base everything on. The big practical problem with this is that not all browsers support all verbs. In practice most of the web is built using GET with a sprinkling of POST. PUT and DELETE are hardly ever used.

This isn't looking so good for the justification for using REST because it works like the web. REST is an extension of the way the web works to accommodate web applications.

As well as web browsers not all frameworks support the full range of verbs either. Even when they do support say PUT it can be difficult to find out how to make it all work because GET and POST do most of the work in most situations that aren't using REST.

So if you want to be truly RESTful you have to create URLs that specify resources and GET, POST, PUT and DELETE to manipulate them. Exactly how this is suppose to work in relation to what you are trying to do can be difficult to see but there are really only two special cases the singleton and the collection:

• If the URL specifies a single instance of something e.g. an order then GET retrieves the order, PUT creates the order specified, POST adds an entity or an attribute to the order and DELTE deletes the order.

• If the URL specifies a collection of entities e.g. a set of orders then GET returns the collection, PUT replaces or creates the entire collection, POST creates a new entity in the collection and DELETE deletes the entire collection.

With a little though you can map any set of operations into the four verbs.

Hypermedia hype

The final major component of REST is the idea usual summed up as  "Hypermedia as the Engine of State". This sounds mysterious but it is simply what we all do when designing a web app - we include links to the next step.

Yes it really is that simple. If you think about it for a moment what links you add to a results page specifies what the user can do next and this is a partial expression of the state of the transaction. So at least the final part of REST is common sense even if it is wrapped up in complicated sounding words. However to suggest that hypermedia can be used to code the entire state of an application - any application - is trying to force too much potential sophistication into one tiny piece of over simplification.

Using REST

Now we come to the really interesting part - making REST actually work.

If you are designing a strict REST based API then you should find it fairly easy fun even. Finding ways to distort the natural structure of your application to fit into RESTs over tight straight jacket is a good mental exercise and when you are finished you can sit back and congratulate yourself on a job well done.

If you want to use a strict REST based API then things start to get much more complicated. The problem is that REST simply provides a set of URLs and HTTP verb interpretations and it is up to the client to figure out how to put these to use.

If you are writing a client from scratch then you can use an HTTP component to conduct the necessary HTTP dialogs but if you want to use a Web client then you have to find a way to build the REST API into it using client side tools.

Getting the browser to submit a particular URL isn't difficult but getting it to submit it using a specific HTTP action is.

A web browser automatically uses GET unless you submit a form when it can use GET or POST. Browsers that support HTML 4 only support GET and POST in forms but later browsers do work with PUT as a form submission method. HTML 5 also does support PUT but this isn't much help as yet. Once again it is  interesting to note that while REST is designed to be like the web a web browser doesn't have to be very  RESTful at all...

Ajax to the rescue

So how do you use a REST API from a browser?

The simplest solution is to use Ajax.

The good news is that most but not all browsers permit XmlHttpRequests with GET, POST, PUT and DELETE. You can even use your favorite JavaScript framework to use a REST API.  For example, the JQuery Ajax object supports all of the verbs providing the browser it is running under does of course.

What this means is that you can now create a web page that uses a REST API to perform CRUD like operations and use hypermedia (i.e. links) to maintain it state. 

But wait - we have a paradigm clash. If you want to use Ajax then one of the ideas you might want to use is the web page as app. Don't move off the URL or reload the page just keep working using XmlHttpRequests. The URL of the page now has no association with a resource, unless you want to think of the entire app as the resource. Using REST in this form suddenly doesn't look much like the web that it is trying to mimic. In fact Ajax is the new stateful client driven web and strict REST isn't looking as relevant any more.

The cross domain problem

Now let us come to the final problem with REST and for many it is the reason that the whole project is so difficult for the beginner to make use of.

So you set up your RESTful API to provide some service or other to clients. This can be arranged to work just fine as long as the client is viewing a web page from your site. If you hope however that your API will catch on and be used by other sites then you hit the gotcha - the same origin policy. Unfortunately you can't make an HTTP request to any site other than the one that the page originated from.

This more or less puts a stop to a REST API being usable by other sites in any simple way.

There are ways around it and HTML5 inter-page messaging makes it much more possible. There are a number of ways around the problem JSONP,  CORS and libraries such as XDM but they all seem out of place in an attempt to build an elegant strictly RESTful solution.

The only practical way to use a REST API within a page served from another domain is to build a proxy.  That is on the server you write some code that will pass the Ajax requests on to the cross domain. Again not elegant, not secure and not much fun.

The cross domain problem is one that dogs other attempts to create APIs that can be used cross domain but some how the whole idea of using URLs as an API seems to promise the ease with which a typical user browses the web. You can't really build a client app that browses a RESTful API.

So are there other designs that work more easily than REST? The simple answer is not really but there is no particular reason to think that REST is the only possible choice. Use URLs to identify resources in a structured way. Create a structured uniform orthogonal command set but don't feel you have to work with the HTTP verbs. Use hyperlinks to provide the user with state information but do invent other stateful mechanisms if they are necessary.

Strict REST is too RESTrictive!

<ASIN:0596805829>

<ASIN:0596801688>