RE: POST vs. separate methods

Not at all!!!! Feature X can be triggered by any media type that is
defined to perform that action. So copy would initially be performed
through application/copy. There is nothing stopping application/foobar
from also doing copy. In addition all the mime types we are defining are
versioned. So if you don't like application/copy as we have defined it,
no problem, just change the version number in the mime file and
implement anything you want. There are no restrictions. We may even want
to create a header to indicate the version of the enclosed mime file so
you can negotiate on that as well. That is a much more powerful form of
negotiation then we currently have with methods.

Thus you can negotiate any kind of copy you want. Including querying the
server to see if it supports application/foobar. It is generic,
negotiable, and brain dead easy to implement. 

In addition we need to differentiate between requesting an action and
performing an action. When you make a copy request nothing actually
happens. What you have done is requested that the server take certain
actions on your behalf. Conceptually the copy doesn't occur until the
server goes out and performs a bunch of GETs and PUTs. A COPY method is
meaningless without its content body. Unlike GET or HEAD where all the
information about the request is in the header, for operations like
COPY, MOVE, and RENAME, the entity-body contains the critical data.
Originally we were going to sidestep this problem by introducing a
billion new headers which would allow us to put all the information
about a COPY in the header but we understand that this wasn't a good
idea.

Thus introducing a bunch of new methods buys you nothing. The real
action is in the content type.

				Yaron

>-----Original Message-----
>From:	Daniel W. Connolly [SMTP:connolly@beach.w3.org]
>Sent:	Tuesday, November 05, 1996 8:59 PM
>To:	Roy T. Fielding
>Cc:	w3c-dist-auth@w3.org
>Subject:	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 Wednesday, 6 November 1996 19:13:14 UTC