RE: POST vs. separate methods

I have discussed this off line with Roy and frankly I think this is a
religious issue. Roy and I have fundamentally different visions of what
HTTP should become. As with the attributes discussion, I do not believe
this issue can resolved on this list in anything like a reasonable
amount of time. This is another issue that should be dealt with at the
November conference.

I realize that pushing stuff off to November sounds like whimping out
but I have seen these discussions roll on in e-mail and they take
forever and rarely resolve themselves. It is only when you get people in
a room that you can get any kind of resolution. These issues are too
fundamental to be argued out on an e-mail list.

			Yaron

>-----Original Message-----
>From:	Roy T. Fielding [SMTP:fielding@liege.ICS.UCI.EDU]
>Sent:	Saturday, November 02, 1996 3:53 AM
>To:	w3c-dist-auth@w3.org
>Subject:	Re: POST vs. separate methods 
>
>> The issue is change control: once you define the semantics of a new
>> method, there's little or no way to change it or update it. Adding new
>> methods is currently (intentionally) difficult. PEP might make it
>> easier, but I'll believe in PEP when I see more progress on it. 
>> 
>> On the other hand, there's a well defined mechanism for defining,
>> modifying, agreeing on, registering new media types.
>> 
>> So "POST with new media type" isn't equivalent to "new method" in the
>> important dimension of "what happens if we get it wrong".
>
>I'll disagree with Larry and Yaron on this one -- there is a giant difference
>between using media types to define the intended action and using methods
>to define the intended action.
>
>  a) access control is based on methods, not media types.  It is true that
>     you could change all WWW software and HTTP semantics such that you
>     could do access control via media types, but there had better be a
>     damn good reason for it [I haven't seen any yet].
>
>  b) the HTTP interface is designed to be capable of being the interface
>     to a general object store, where the method really is an OO method
>     to be applied to an object.  For a variety of reasons, it is better
>     to have separate names for separate semantics, rather than a single
>     name for all method calls and having the object determine the
>     semantics by some case-based switch on one of the parameters.
>
>I'll also disagree with Larry on the notion of media types being any
>easier to change than methods.  Anybody ever try to change
>
>     application/x-www-form-urlencoded
>
>(the media type used by default in WWW form-based entry)?  That was an
>incredibly poor design decision, known from the start, and yet we still
>can't get rid of it.
>
>I personally would rather have the definition of standard methods go through
>the RFC process; non-standard methods don't have to go through any process.
>As an implementer, it is easier (and better) to add support for a new method
>to the Apache server than it is to add access control by media type.
>
>If you get it wrong, just change the method name.
>
>.....Roy
>

Received on Sunday, 3 November 1996 18:56:36 UTC