Re: POST vs. separate methods

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

Surely this isn't a HTTP semantics issue, but it is a WWW software
issue. HTTP access control policy is completely up to the server, and
if you wanted to write a server that allowed POST-ing .png files and
but not .gif files, I don't think that would change the semantics of
HTTP at all.

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

The first sentence is a stretch, but I'll go along with it. And I'll
agree with the second sentence. But we're frequently bluring the
semantics of a whole host of operations under 'POST'.

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

Well, actually, I did try to change application/x-www-form-urlencoded

RFC 1867: Form-based File Upload defines

and I think it's been modestly successful: there are applications that
now use it for form submission. Those applications didn't need a
change to HTTP to do so.

But I agree, this is a weak argument. We should just be careful that
we have the semantics we'll want for a while before we start putting
in 'PATCH' and 'REVERT-TO-VERSION' as HTTP methods.