REST Issues, Real and Imagined
Tuesday, 27 February 2007
I think that most of the debate about REST focuses on the wrong things, leading developers down the garden path at the expense of their productivity and the success of their projects. Time and time again, I’ve seen folks who are new to REST get caught up on small stuff like this;
False Choice: “High” vs. “Low” REST Lots of blog space has been devoted to figuring out what PUT and DELETE are good for, leading many to believe that they have to choose a direction, “High” or “Low” (as popularised by Don). I’ve seen developers who decide they can’t do “pure” REST, and so think that the only alternative is POX-style RPC services, with nothing in between.
This isn’t an earth-shatterning choice to make; the truth is that you’re just choosing what methods you’ll use, based on the semantics of your application, and how well those methods are chosen by the tools you’ll use. Is this a reason for a schism in the Web? Hardly; there are much more fundamental splits in WS-* services (e.g., whether to use SOAP encoding, RPC, etc.).
Red Herring: The Evils of POST If you dip into REST discussions a bit, you may leave with the impression that POST is the anti-REST, and it should be avoided at all costs. However, if that’s true, why did the Great Roy allow POST to be foisted upon HTTP? Perhaps it has a place in RESTful applications after all — as long as it’s used intelligently.
This usually becomes obvious when you’re deep in the bowels of resource-modelling an application, trying to figure out how to represent a complex operation as state — only to realise that there’s no need to expose all of the details, if there were just some way to say “hey, submit this for processing!” POST is the correct answer.
Red Herring: URI Design When somebody first “gets” REST, they often spend an inordinate amount of time agonising over the exact design of the URIs in their application; take a look over on rest-discuss, for example. In the end, though, URI design is a mostly a cosmetic issue; sure, it’s evidence that you’ve thought about good resource modelling, and it makes things more human-intelligable, but it’s seldom worth spending so much time on it.
I’d worry a lot more about cacheability, extensibility and well-defined formats before blowing out my schedule on well-designed URIs. For me, the high points are broadly exploiting the hierarchy, allowing relative references, and making sure that tools (e.g., HTML forms) can work well with my URIs; everything else is gravy.
Red Herring: Cookies Are Bad Cookies get a lot of grief, and they are certainly abused on the Web today. However, they’re not intrinsically bad; there are uses where they’re appropriate, as long as they don’t try to do the job of the URI as well. Given the poor state of the standard mechanisms for HTTP authentication, for example, it’s not unreasonable to use them for passing credentials.
False Choice: Machines vs. People There’s an insistence from some quarters that somehow, HTTP and REST are only good for people sitting behind browsers. I think that this has been solidly and obviously disproven, and find it difficult to believe that such continued, vigourous assertions are anything other than FUD. shrug
How About Some Real Issues with REST?
All of the above is not to say that there isn’t anything to improve about the state of HTTP and REST in the world.
The most obvious issue that everybody trips up over is authentication — HTTP authentication is unbelievably primitive, and while there are promising things on the horizon, we’ve still got a long way to go.
Another issue is shared with ws-* services; formats are hard. In particular, while XML is popular, most use of it is horrible, and the tools don’t encourage good practice. You could count the number of people who can write an XML schema that’s extensible and versionable on both hands. JSON is promising, but it doesn’t have a schema language, and it’s also pretty limited.
The tools for REST are primitive as well; Marc’s JSR looks promising in this direction, but a lot more work needs to be done, in a number of dimensions.
Finally, one of the deeper REST constraints is using hypertext as the engine of application state. Designing applications and tools that are smart enough to update themselves based upon what happens on the Web isn’t in reach for today’s tools. That’s not to say that they’re not possible.