On 30/03/2011, at 3:25 PM, Julian Reschke wrote:
> On 30.03.2011 16:02, Cameron Heavon-Jones wrote: >> Existing servers don't do this for PUT or DELETE but then existing servers >> don't currently support these methods from forms anyway. > > What exactly does it *mean* to support these methods "for forms"? It is so that a user can interact with a resful service using plain html (no ajax) in the same way that automated agents can. This means a user must be able to initiate any method of HTTP request, and the only way of doing that in html is through a form. That forms only support GET and POST just precludes real humans from interacting with restful systems. That PUT and DELETE are idempotent doesn't mean that forms can't send them, it just means that the service methods must be designed as such. This is the way that this currently works for automated agents, there is nothing special about a user agent which precludes it from sending these types of requests. A form is just a UI element for allowing a user to interact with the same service which everything else already does. For a form to send a DELETE doesn't seem to make much sense, but this is only due to the flexibility of the form element in being able to capture any amount of request data. This data seems at odds with a method like DELETE which appears to be a non-configurable operation. However, it does make sense that for an idempotent operation there almost should be some some additional arguments - maybe even just a hidden version number. > >> Servers don't need special cases for requests from forms, they need special >> cases based on what content type the agent says it can handle. > > I'm not convinced that the Accept: header would be reliable here, but it > could be worth a try. > > Best regards, Julian I think this must be supported... if an agent wants xml it should get xml, if it wants html it should get html. To just give up and not allow or provide any content is to not support anything. cam
