Re: [Fwd: Re: PUT and DELETE methods in 200 code]

Hi Arthur,

If you will engage in heresy, i will oblige with some evangelism :) Not because this is the place for a debate on ReST but because it is pertinent to framing the requirements of the form element in HTML5. I will try to keep my responses within this context.

On 02/04/2011, at 4:22 AM, Arthur Clifford wrote:

> I realize this may be heresy, but why is using PUT and DELETE appropriate? And why should HTML 5 or any version of HTML be considered an application development language rather than a hyper-text markup language?

I think the question can be seen from the alternative perspective of - why is using PUT and DELETE inappropriate? I will answer this below.

To answer the definition of HTML you only need to look at the charter's deliverables:

"A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web."

> I would argue that the nuance of post and has historically been blurred since GET pretty much meant a CGI URL and thus had a character limit while POST was unlimited. So many of us in the field just stuck with POST even for GET operations when user input, or number of parameters went past that limit.

> Frankly, I think that the user agent requesting content via a URL should be required to do a GET, and that Forms should be required to POST, and that the method attribute be done away with to avoid confusion. REST is just remote proceedure calls. I think that PHP's superglobal $_REQUEST shows the practical perspective of things; no matter what you are doing it is just a request that you are providing parameters to. I don't think the industry standard should change to reflect an academic presumption that the HTTP POST, DELETE, GET, and PUT are "the right way" to do post parameters to a remote procedure call. There needs to be a distinction between the transfer protocol (HTTP) and the the functionality of the remote procedure calls.

I think you have a misunderstanding of what ReST is and what it is not. I would recommend you read Roy Fielding's dissertation on ReST, specifically in the context of the WWW, sections 6.5.2 - "HTTP is not RPC" and 6.5.3 - "HTTP is not a Transport Protocol".

http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2

ReST is an architectural style and an implementation of that style is the WWW - this is the architecture which marries URIs, HTTP and HTML into a single system. This *is* how the WWW works and for an example of a true ReSTful system you need look no further.

That HTML and HTTP are interlinked is because they are part of the same system. For HTML to not include full support for HTTP is to exclude one part of the system from full interaction. As HTML is the user-interface for humans to interact with resources over HTTP this limitation would be only to limit real humans from interacting with resources to the full extent that automated systems can. 

This isn't about an academic presumption, this is about the architectural implementation of the WWW and for the HTTP protocol to be accessible to real humans.

> Furthermore there are nuances to GET and POST that aren't as obscure as those referenced so far in this thread. Safari, for instance, when you do GET operations even via HTTPS displays the URLS that are accessed in its Activity window in clear text. Even if you are getting content via HTTPs you need to post the parameters in order to have them encrypted. I think that is where the distinction of protocol vs remote procedure call methodology is most distinct. HTTP crud operations should NOT be used for RPC methods and they should not be confused. If REST developers, and I am one, want to distinguish between put,get, update, and delete they can create REST scripts for doing that and it would take less effort that it would to refactor the entire industry. This issue is not an HTML nor an HTTP issue is it a server-side REST API issue.
> 
> That's my heretical 2-cents,
> 
> Art
> 
> 

There is nothing stopping PUT or DELETE requests from containing body content. Your misunderstanding of ReST as RPC is due to you thinking that there is only one type of operation - to 'post' data. The HTTP specification has GET, PUT, POST, DELETE, HEAD, OPTIONS, etc because each of these are their own methods with their own semantics and unique effects\operations in the context of a resource. HTTP is like an implementation of RPC, you don't implement RPC under HTTP.

Cam

> 
> On Apr 1, 2011, at 6:33 PM, mike amundsen wrote:
> 
>> Subbu:
>> 
>> Not sure of your question, so I'll take a shot:
>> 
>> *** You might be asking if the conditional header should be present in
>> the body at all.
>> Consider cases where the response contains a list of possible
>> resources to PUT/DELETE, each possibility rendered as a FORM with the
>> response representation:
>> 
>> <html>
>> ...
>> <h1>Unresolved Orders</h1>
>> <form action="..." method="delete" if-match="q1w2e3"><label>Order
>> #123</label><input type="submit" value="delete" /></form>
>> <form action="..." method="delete" if-match="w2e3r4"><label>Order
>> #456</label><input type="submit" value="delete" /></form>
>> <form action="..." method="delete" if-match="e3r4t5"><label>Order
>> #789</label><input type="submit" value="delete" /></form>
>> ...
>> </html>
>> 
>> In the above example, the Etag of the response representation would be
>> insufficient as that Etag belongs to the entire response, not any of
>> the resources represented by each form in the body.
>> 
>> 
>> 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 21:07, Subbu Allamaraju <subbu@subbu.org> wrote:
>>> Do you need the conditional headers as form parameters? The agent should be able to replay those headers.
>>> 
>>> Subbu
>>> 
>>> On Apr 1, 2011, at 5:50 PM, mike amundsen wrote:
>>> 
>>>> Cross-posting to related groups:
>>>> 
>>>> 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 16:24, Sam Ruby <rubys@intertwingly.net> wrote:
>>>>> On 04/01/2011 03:29 PM, Julian Reschke wrote:
>>>>>> 
>>>>>> On 01.04.2011 21:04, Sam Ruby wrote:
>>>>>>> 
>>>>>>> On 04/01/2011 02:01 PM, Nathan wrote:
>>>>>>>> 
>>>>>>>> fwd'ing to some relevant lists - would be very happy to see a proper
>>>>>>>> response from W3C / HTML WG chairs, particularly the question "And
>>>>>>>> *where* should this activity happen?"
>>>>>>> 
>>>>>>> Where is in bug reports:
>>>>>>> 
>>>>>>> http://dev.w3.org/html5/decision-policy/decision-policy.html
>>>>>>> 
>>>>>>> Should you (or anyone) wish to escalate a proposed RESOLUTION by the
>>>>>>> editor, you will be encouraged to join the working group and participate
>>>>>>> by creating a proposal and participating in the discussion:
>>>>>>> 
>>>>>>> http://www.w3.org/html/wg/#join
>>>>>>> 
>>>>>>>> best, nathan
>>>>>>> 
>>>>>>> - Sam Ruby
>>>>>> 
>>>>>> I'm currently interested in a discussion that leads to something that
>>>>>> *could* be added to the HTML spec, and might lead to clarifications in
>>>>>> the HTTPbis specs.
>>>>>> 
>>>>>> I don't think an issue tracker is the right place for that.
>>>>> 
>>>>> In that case, discussions can happen anywhere; but those that could lead to
>>>>> changes to the W3C HTML spec should occur on public-html to ensure that all
>>>>> of the right people see it.
>>>>> 
>>>>>> Best regards, Julian
>>>>> 
>>>>> - Sam Ruby
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
>

Received on Saturday, 2 April 2011 15:30:12 UTC