Re: PaceServiceError GET vs. POST

[Mark Baker <distobj@xxxxxxx>]

On Wed, Jun 23, 2004 at 12:07:01AM -0700, Greg Stein wrote:
> The simple fact is that you can argue POST is appropriate for EVERYTHING.

You could argue that of course, but you'd be wrong. 8-)

POST means what it says in RFC 2616, and that's anything but
"everything".  POST is simply a generic mutator where the POSTer has
zero visibility into the resulting state of the resource (unlike PUT).
And as a mutator, it is unsuitable for doing queries IMO, not because it
has to mutate (it doesn't), but because queries-over-POST can only be
performed with prior out-of-band negotiation or a single authority
controlling both ends of the pipe.

> "Hey! I'd like that page's contents. Why don't I send it a post and it
> will send back the contents?" "Time to modify the page, let's just POST
> the new content to it." "I wonder what metadata is on that page? Let's
> send a neat little POST to get that back." Nevermind that the better way
> to do these is with GET, PUT, and PROPFIND.

And why are they better?  IMO, because there's a spec that says they
do those things, which reduces the cost of coordination between
uncoordinated parties who have implemented that spec.

> POST is your generic catch-all with zero semantic meaning. I would say
> that you need to _justify_ using it, rather than continue to use it as a
> default position which needs to be argued away from.

It doesn't have zero semantic meaning, it just has a very generic
semantic meaning.  I can think of no method more appropriate for
submitting an error report (even one with no body) than POST.

But do we at least agree that GET is the wrong method?

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.