Designing web applications in a RESTful way from the User Interface perspective can be very challenging and many people argue that REST just isn't suited to user interfaces and should be restricted to Application Interfaces. I've come across this recently when trying to understand why the Bongo Project uses a separate URI scheme for the user interface to the application interface. I've always thought that a resource is a resource, regardless of whether you're a man or a machine. Different people and different machines want different representations of the resource, but it is still the same resource.
Dave Thomas is a pragmatist with knowledge and experience behind him. But in reply to Dave's insightful blog post, The RADAR Architecture: RESTful Application, Dumb-Ass Recipient, I play devil's advocate and put forward an idealistic alternative argument:
From a pragmatic point of view this makes an awful lot of sense because it's easier to bend your server application to the will of millions of existing web browsers than to change the way browsers work.
However, I wonder whether from an idealistic point of view this would be better addressed in the design of the “dumb browsers” you talk about. The dumb browser doesn't need to be quite as dumb if we don't want it to.
What if XHTML forms and Web Browsers *did* support the PUT and DELETE verbs? I'm not familiar with the reasons that browsers do not already support these HTTP methods, but I do know that the original vision Tim Berners-Lee had of a web browser was of an application which could write data as readily as it could read it.
Maybe it is a user interface problem.
Asbjørn Ulsberg asked what a request/response would like if a web browser wants to GET a resource represented as an HTML form so it can edit the information and then PUT it back to the same URI. In answer to his question, I don't believe we should have a MIME type to put into an Accept header specifically for an HTML form view. It's still HTML after all!
Perhaps the answer is that when HTML is displayed in a browser, if the user has write permission, it is editable in the same way that a document in a word processor is editable, rather relying exclusively on forms for user input. If you've ever used Google Docs you may have noticed that if you click on the title of a document, it becomes editable using JavaScript. There is no separate “edit” and “view” mode, it's all one thing so you don't need to tag ;edit to the end of the URI. The reason web browsers themselves don't work this way is probably because the HTML view is only one representation of a resource and it might be hard to translate changes made by the user to this presentation of the information into changes in the underlying data model. Using forms allows the application designer to restrict user input to specific fields in the underlying data model. This is something which needs more thought because I believe it's also the core reason behind the “offline problem”, but that's a different story.
roberthahn writes that “The dumb browser doesn't provide the user with a way of submitting requested Mime types.” Well, again, maybe this is a user interface issue with the browsers, maybe they should! Remember that the web is just a collection of resources, HTML is only one representation of those resources.
If “smart” client interface can specify which representation it wants, why can't a user? Maybe a user should be able to choose whether they want to browse the web in plain text, formatted text, or even 2D or 3D vector graphics or a voice representation of a resource. The user agent could allow the user to choose a particular mode in which to browse the web depending on their current environment, and offer alternative representations where they are available. For devices that are only capable of certain modes of interaction with the user (e.g. a voice interface), this could be fixed by the user agent.
We shouldn't entirely dismiss the idea of changing web user agents themselves, just because it is a difficult option.