cam: Thanks for the feedback. I see the usage scenario you have in mind for the "GET-style" DELETEs.
Other comments make sense to me, too. Thanks. BTW - any chance you can send me the browser matrix for different response-types soon? mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me #RESTFest 2010 http://rest-fest.googlecode.com On Tue, Apr 5, 2011 at 09:31, Cameron Heavon-Jones <[email protected]> wrote: > > On 05/04/2011, at 6:01 AM, mike amundsen wrote: > >> Cam: >> >> my comments are inline... >> >> On Mon, Apr 4, 2011 at 13:03, Cameron Heavon-Jones <[email protected]> >> wrote: >>> Feedback on: Supporting PUT and DELETE with HTML FORMS @ 2011-04-04 >>> >>> 1.2. Assumptions >>> >>> I think that DELETE requires the same support as PUT and POST. The >>> requirement for this was posted to public-html-comments: >>> >>> http://lists.w3.org/Archives/Public/public-html-comments/2011Apr/0020.html >>> >>> I would suggest that DELETE uses the same URI encoding rules as for GET by >>> default, with the option of also being allowed to be encoded in the same >>> enctypes as for PUT and POST. This will allow for a DELETE request using >>> query parameters to be constructed through a form or, for the other >>> enctypes, for the DELETE request to be embedded with configurable >>> attributes. >>> >>> For example, it would be great to be able to generate a DELETE request to a >>> uri like: >>> >>> <form action="http://example.org/user"” method=”delete” if-match="*"> >>> <input name="hat-size" type="text" value="" /> >>> <input type="submit" /> >>> </form> >>> >>> *** REQUEST >>> DELETE user?hat-size=small HTTP/1.1 >>> Host: www.example.org >>> >> >> While I am not personally convinced of this approach for deletes, I've >> added it to the document to make sure it's recorded for discussion. > > Great, thanks. > > To illustrate it's usefulness, i would frame the requirement in response to a > user's problem. > > What other mechanism would be available for a user to issue DELETE over a > collection of sub-resources? > > To continue with the example of users, if the base user resource is /user and > each individual user is located at /user/{id}, what mechanism is there to > issue a DELETE request covering a sub-set of users? > > If we can issue requests to GET a sub-set of sub-resources, and if that is > deemed to be a valid resource, then why can we not issue a DELETE over the > same resource? ie > > GET /user?hat-size=small > > DELETE /user?hat-size=small > > these are both valid resources and hence both valid requests. > > the problem is now whether it is possible for a user to initiate this request > for DELETE as they currently can for GET. > >> >>> >>> 4.4. Optional Added FORM Content-Types >>> >>> I'm not sure there is need to add JSON to form entypes. As JSON is >>> javascript data format it could be expected that this be used only with >>> XHR. Maybe a use case for support would be if javascript were required to >>> manipulate data prior to the request being sent, but then couldn't JS just >>> create the JSON from the form itself? >> >> Understood. >> >>> >>> >>> 4.5. Optional Support for Prefer Header >>> >>> I don't think this is necessary, if Accept header is adhered to. Without >>> knowing the full context the Prefer header was targeted at, I'm not sure i >>> understand the need for it, especially in this context. >> >> The Prefer I-D offers agents the ability to use settings such as >> "send-no-content", "send-status-only", etc. when making requests. I >> don't see a way to do this w/ Accept headers right now. >> >> Again, I think this "Prefer" header is interesting for HTML.FORMS, but >> not a pre-requisite for supporting PUT/DELETE. > > I think the Prefer header is interesting...though i am unconvinced that it is > necessary, or even useful for html. > > Automated agents would seem to gain the most from its inclusion, but then > html isn't really for them anyway. > >> >>> >>> >>> 4.6. Support for Atom-Style PUT/DELETE >>> >>> I would be inclined to remove any default application of etags. If the >>> server has full access to etags (and full understanding), why can it not >>> just apply to the form as or if required? >> >> Understood. I, too, am not convinced of this option. However, GET >> makes regular use of ETags already. >> > > OK. No problems. > > Thanks, > Cam > > >>> >>> >>> cam >>> >>> On 04/04/2011, at 5:41 AM, mike amundsen wrote: >>> >>>> All: >>>> >>>> I've updated/reformatted the PUT/DELETE with HTML FORMS document[1] >>>> with the following: >>>> - Added "integrate w/ existing servers..." to the Goals section. >>>> - Added "Binary Transfers" to the Scenarios section. >>>> - Added Julian Reschke's query regarding exsting browsers handling >>>> 201/202/204 response to the Handling Responses section. >>>> - Added "Optional Added FORM Content Types", "Optional Support for >>>> Prefer Header", and "Support for Atom-Style PUT/DELETE" to the "Other >>>> Considerations" section. >>>> >>>> I think this reflects the key feedback from the last couple days. >>>> >>>> I've not had time to doing any research/testing on Julian's query >>>> regarding current browsers' handling of 201/202/204 responses. I >>>> figure browser folks can chime in here, eh? >>>> >>>> NOTE: I've cross-posted this to: >>>> - ietf-http-wg >>>> - public-html >>>> - public-html-comments >>>> >>>> If this is overkill, let me know. >>>> >>>> [1]http://amundsen.com/examples/put-delete-forms/ >>>> >>>> mca >>>> http://amundsen.com/blog/ >>>> http://twitter.com@mamund >>>> http://mamund.com/foaf.rdf#me >>>> >>>> >>>> #RESTFest 2010 >>>> http://rest-fest.googlecode.com >>>> >>>> >>>> >>>> >>>> On Fri, Apr 1, 2011 at 17:48, mike amundsen <[email protected]> wrote: >>>>> I've posted a document[1] that shows one way in which HTML FORMS can >>>>> support PUT/DELETE w/o the need for plug-ins or scripting. It's a >>>>> quick draft but I think it covers the basics. >>>>> >>>>> If this is not in the desired format let me know. >>>>> >>>>> >>>>> [1] http://amundsen.com/examples/put-delete-forms/ >>>>> >>>>> mca >>>>> http://amundsen.com/blog/ >>>>> http://twitter.com@mamund >>>>> http://mamund.com/foaf.rdf#me >>>>> >>>>> >>>>> #RESTFest 2010 >>>>> http://rest-fest.googlecode.com >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Apr 1, 2011 at 14:26, mike amundsen <[email protected]> wrote: >>>>>> <snip> >>>>>>> Personally I'd like to see a concrete proposal how PUT and DELETE will >>>>>>> work >>>>>>> (examples with HTML and HTTP interaction). Right now it's totally not >>>>>>> clear >>>>>>> to me. >>>>>>> >>>>>>>> And *where* shod this activity happen? >>>>>>>> - here >>>>>> </snip> >>>>>> >>>>>> Makes sense to me; I'll work up a few examples of HTTP/HTML this >>>>>> evening and post a link. If/when others do the same we can use them >>>>>> all as references in any discussion. >>>>>> >>>>>> mca >>>>>> http://amundsen.com/blog/ >>>>>> http://twitter.com@mamund >>>>>> http://mamund.com/foaf.rdf#me >>>>>> >>>>>> >>>>>> #RESTFest 2010 >>>>>> http://rest-fest.googlecode.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 1, 2011 at 14:14, Julian Reschke <[email protected]> >>>>>> wrote: >>>>>>> On 01.04.2011 15:41, mike amundsen wrote: >>>>>>>> >>>>>>>> I see the bug has been re-opened. >>>>>>>> >>>>>>>> I see there has been some discussion on public-html-comments regarding >>>>>>>> PUT/DELETE[1]. >>>>>>>> I also note at least one suggestion in that thread was to discuss this >>>>>>>> on the whatwg list[2]. >>>>>>>> >>>>>>>> What is the preferred way to proceed here? >>>>>>>> - List concerns/reservations and deal with them as they come up? >>>>>>>> - Draw up a straw man proposal (is there a standard format for this)? >>>>>>>> - Some other process? >>>>>>> >>>>>>> Personally I'd like to see a concrete proposal how PUT and DELETE will >>>>>>> work >>>>>>> (examples with HTML and HTTP interaction). Right now it's totally not >>>>>>> clear >>>>>>> to me. >>>>>>> >>>>>>>> And *where* shod this activity happen? >>>>>>>> - here >>>>>>> >>>>>>> Here should be fine. >>>>>>> >>>>>>>> ... >>>>>>> >>>>>>> Best regards, Julian >>>>>>> >>>>>> >>>>> >>>> >>> >>> > >
