Do I need a REST?
Posted by Graham Stratton Fri, 27 Oct 2006 10:25:05 GMT
I’ve been trying to work for too many hours a day recently, so I thought I’d try to take a bit of a break today. So I’m spending it reading up on some of the things that I think I ought to know about but don’t.
I had a quick look at Schevo earlier. Schevo (abbreviating schema evolution) is a tool which builds on top of an Object database, such as the ZODB or the much smaller but less powerful Durus. It allows you to specify schema, unique keys and other features associated with relational databases. Thus the idea is to provide some sort of hybrid system with enough advantages of both to be better than either for some tasks, in particular rapid web development – not a minor market. There seems to be a severe lack of examples and little discussion since it was presented at Pycon in 2005, but work on it is still progressing. This is definitely something I’d take a closer look at if I had an infinite amount of time.
Back to the intended topic of this article: REST, short for REpresentational State Transfer. It’s something that is increasingly talked about, and some people seem to be very passionate about, but is it something I need to take seriously?
Firstly, the term REST is not being used in exactly the way it was originally intended. As the Wikipedia article says:
The name “REST” is, circa 2006, finding frequent use in a loose sense to describe some programmatic interfaces to portions of the World Wide Web that use Extensible Markup Language (XML) (or, less commonly, YAML, Javascript Object Notation (JSON), or plain text) over the Hypertext Transfer Protocol (HTTP) without an intermediate messaging layer. This usage of the name “REST” serves to distinguish the interfaces from those interfaces which employ Simple Object Access Protocol (SOAP) or remote procedure call (RPC).
So, it’s all about web services, then, and those of us who are producing browser-based stuff can ignore it? Well, maybe. But one of the great advantages of REST-based interfaces is that the XML can easily be modified, for example by XSLT, into standard user interfaces, provided that one has used one’s GETs, PUTs, POSTs and DELETEs correctly. So the line between a web service and a browser-accessible service isn’t as clear as you might expect.
The discussion of SOAP versus REST is an interesting one; for one side of the argument, Paul Prescod has an article on the benefits of REST. Paul gives a lot of reasons that REST is better than SOAP. To add one more, SOAP isn’t as Simple as it might be.
An analogy
I often object to analogies. And I don’t think OO programming is the solution to everything either. But still, where SOAP and RPC are internet versions of procedural programming, REST is about objects. When using REST, URIs should refer to resources, not to services. I do feel that REST is better for it, though this does mean that all the things you can do to a resource have to be done through a predefined set of methods.
SOAP also requires the caller of a function to know about the parameters it takes. It’s a complex situation, and WSDL might make it easier, but it feels rather a lot like the unresponsive world of static typing to me. I don’t think it’s surprising that the dynamic-typing people are nearly all REST supporters.
More on REST/SOAP
I haven’t managed to cover the debate very well; I suggest anyone interested reads Paul Prescod’s REST/SOAP debate. There, he points out that inventing new protocols is bad, HTTP is good enough for most things, that the great strength of HTTP is URIs and that being able to just GET any object provides a great deal of power.
Summary for Web Developers
But getting back to what people developing web sites need to know. Well, you should use POST if you’re going to change anything, and GET otherwise. Repeated calls to a GET request should return the same thing. Well, sort of. To be more precise, making a GET request now shouldn’t affect the result of making a GET requeest in a minute’s time.
GET requests can be cached. If you try to repeat a POST request by using the back button in your browser, then you will be warned, which is what you probably want before a state-changing request. So POST is safer than GET. There are also a couple of other reasons to use POST: GET parameters are encoded in the query string, which means that the length of the parameters is limited and that non-ascii characters cannot be encoded.
Browsers don’t currently support anything other than GET or POST, though. According to HTTP, POST should be used to create a new object, PUT to modify and object and DELETE – well, yes. For a web service you’d do that correctly. The Rails people have announced ActiveResource, which makes it easy to create a web service, and supports a hidden field so that browsers pretend to do PUT and DELETE properly.
Isn’t it all a mess? One thing which isn’t is the question of how to easily create a link to a POST request without having to create a form. It seems that using a query string is an equally valid approach in POST as it is for GET, though you’ll have to work out what your library does with the query string parameters once it receives them, which may depend on the request type.
