- From: Jeffrey Winter <JeffreyWinter@crd.com>
- Date: Wed, 12 Feb 2003 10:15:14 -0500
- To: "Miles Sabin" <miles@milessabin.com>, <www-tag@w3.org>
> But there's a crucial difference. My proposal (which is really only a > minor variation on Patricks) uses a _request_ header, to > allow clients > to actively request metadata. The current > distributed-registry proposal > only allows servers to provide unsolicited metadata responses. The problem is that if you are using a GET with a Meta: header, then are you really getting a representation of the resource? It seems to be stretching the semantics of the GET method. Also, how do you PUT/DELETE/POST to that metadata, just using the Metadata: header? It seems morally equivalent to a set of M(XXXX) methods which has the same problem. The only issue with having the OPTIONS method return a Meta-Location: header is that it takes multiple requests to obtain the data, an OPTIONS request to get the uri of the metadata, and a GET on that uri to actually obtain it. I see this as both beneficial and necessary. Really the only difference between this mechanism and the one proposed by Costello et al [1], is that it uses the OPTIONS method to bind the resource to it's metadata and thus avoids the issue that Fielding brought up of always having the extra header. [2] [1] http://www.xfront.com/dist-reg/distributed-registry.html [2] http://groups.yahoo.com/group/rest-discuss/message/3315
Received on Wednesday, 12 February 2003 10:15:29 UTC