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

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

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



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 03:22:54 UTC