Subject: Re: PUT and DELETE methods in 200 code

From: mike amundsen <[email-masked]>
Date: Fri, 1 Apr 2011 09:41:52 -0400

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?

And *where* should this activity happen?
- here
- public-html-comments
- whatwg
- buglist
- etc.

[1] http://lists.w3.org/Archives/Public/public-html-comments/2011Mar/thread.html
[2] http://lists.w3.org/Archives/Public/public-html-comments/2011Mar/0026.html

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

#RESTFest 2010
http://rest-fest.googlecode.com

On Wed, Mar 30, 2011 at 10:31, Julian Reschke <[email-masked]> wrote:
> On 30.03.2011 16:02, Dominik Tomaszuk wrote:
>>
>> Hi all,
>>
>> In [1] there are specified HTTP methods in 200 code. I think that this
>> section should be extended to PUT and DELETE methods, because in [2] and
>> [3] authors write references to 200 code [1]. In my opinion PUT and
>> DELETE methods can be defined the same as POST (a representation
>> describing or containing the result of the action). It could be very
>> helpful especially for RESTful applications.
>>
>> [1]
>>
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.2.1
>> [2]
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-7.6
>> [3]
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-7.7
>>
>> Regards,
>>
>> Dominik Tomaszuk
>
> Hi Dominik,
>
> thanks for coming over here to discuss this.
>
> Let's have a look at PUT. Three things that come to mind what a 200 response
> could carry are:
>
> - nothing (the server did what you asked for, and that's really all you need
> to know) -- this is what many (most) WebDAV servers will do
>
> - return a small status message
>
> - return the new representation of the resource
>
> There are probably more options. I'm not sure the HTTP spec can/should
> mandate any.
>
> So also recent discussion of "Prefer"...: starting at
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/0291.html>.
>
> BR, Julian
>
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Apr 2011 20:14:36 +0200

> - Draw up a straw man proposal (is there a standard format for this)?

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

---

From: mike amundsen <[email-masked]>
Date: Fri, 1 Apr 2011 14:26:33 -0400

<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.
>
</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

#RESTFest 2010

On Fri, Apr 1, 2011 at 14:14, Julian Reschke <[email-masked]> wrote:
> 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.
>

---

From: mike amundsen <[email-masked]>
Date: Fri, 1 Apr 2011 17:48:45 -0400

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

#RESTFest 2010

---

From: mike amundsen <[email-masked]>
Date: Mon, 4 Apr 2011 00:41:55 -0400

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

#RESTFest 2010

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Mon, 4 Apr 2011 18:03:49 +0100

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

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?

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.

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?

cam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Apr 2011 19:13:46 +0200

> DELETE user?hat-size=small HTTP/1.1

What's the use case for the "other" encoding (form field in payload)???

Best regards, Julian

---

From: mike amundsen <[email-masked]>
Date: Tue, 5 Apr 2011 01:01:37 -0400

Cam:

my comments are inline...

> DELETE user?hat-size=small HTTP/1.1

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.

> 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…

Understood.

> 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 co…

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 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.

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Tue, 5 Apr 2011 14:31:19 +0100

> 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.

> 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.

> makes regular use of ETags already.

OK. No problems.

Thanks,
Cam

---

From: mike amundsen <[email-masked]>
Date: Tue, 5 Apr 2011 09:56:48 -0400

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

#RESTFest 2010

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Tue, 5 Apr 2011 15:06:13 +0100

Will get the browser matrix to you today or if held back then for tomorrow. Sorry for the delay!

cam

---

From: mike amundsen <[email-masked]>
Date: Tue, 5 Apr 2011 10:07:10 -0400

> Will get the browser matrix to you today or if held back then for tomorrow. Sorry for the delay!

no problem at all. thanks in advance.