- From: Daniel W. Connolly <connolly@beach.w3.org>
- Date: Wed, 06 Nov 1996 00:59:05 -0400
- To: "Roy T. Fielding" <fielding@liege.ics.uci.edu>
- cc: w3c-dist-auth@w3.org
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