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