- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 30 Mar 2011 17:06:11 +0200
- To: Cameron Heavon-Jones <cmhjones@gmail.com>
- CC: "T.J. Crowder" <tj@crowdersoftware.com>, Dominik Tomaszuk <ddooss@wp.pl>, public-html-comments@w3.org
On 30.03.2011 16:58, Cameron Heavon-Jones wrote: > > > 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. > ... So for PUT, where do you want the form fields to go? URI? request body? Best regards, Julian
Received on Wednesday, 30 March 2011 15:13:31 UTC