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