Re: POST vs. separate methods

In message <199611060431.AA10149@mta4.nts.uci.edu>, "Roy T. Fielding" writes:
>
>I understand that it is possible to ignore that and to do everything under
>a single method and to encapsulate the semantics of the request within
>the message body.  The reason we don't do that is [...]
>it also frees the media type from having any semantics other than
>"this is the format of what is contained within the body." 

Ah! Terribly good point: if we say that feature X is triggered
by using media type MX, then we've lost the ability to use
other data formats to do X; we've lost the traditional
'format negotiation' degree of freedom.

One way to address that is to make sure MX is a compound (aka
multipart) data format with a typed 'payload' subpart. But
that starts to get contorted Real Fast.

So I'm in favor of separate methods for COPY, MOVE, RENAME,
and other long-standing filesystem operations. My convictions
are less strong about less traditional idioms like BROWSE,
LOCK, etc., but my intuitions are in the same direction.

The only time I struggle with the issue is when the operation can be
piggy-backed on GET, PUT, or POST with 'carrier wave' headers; for
example, GET-with-lock could use a GET method with funky headers.
That reduces the:

	C: LOCK R
		S: 2xx OK, here's the lock
			---or---
		S: 5xx Huh? what's LOCK?
	C: GET R
		S: 200 OK, here's the document
conversation to:
	C: GET-with-lock R
		S: 2xx OK, here's the document and the lock
			---or---
		S: 200 OK, here's the document (doesn't grok with-lock)

Even that's a bad example, since consuming a resource like a lock
is a goofy thing to do in an idempotent[sic] method like GET.

Dan

Received on Tuesday, 5 November 1996 23:53:45 UTC