I'm curious about the need for these extension headers you propose. Isn't that what the OPTIONS method is for? Shouldn't you be able to do an OPTIONS request on the resource itself and have whatever meta information returned? That way there's no need for two resources with links back to each other.
- Jeff
-----Original Message----- From: Roger L. Costello [mailto:costello@...] Sent: Tuesday, January 21, 2003 2:11 PM To: rest-discuss Subject: Re: [rest-discuss] REST Resource Discovery
Hi Folks,
See here for a discussion of discovering a resource's metadata, and vice-versa:
"S. Mike Dierken" wrote: > > ----- Original Message ----- > From: "S. Alexander Jacobson" <alex@...> > > > Questions that I think need to be answered: > > 1. How do you know what MIME-types one may POST or > > PUT to a given resource? > > > > My proposal is that servers return accept-POST and > > accept-PUT headers in response to GET requests, > > however these headers are not actually defined > > in any standard so perhaps there is another > > approach. > > I would like a solution to this problem also, I think it would help promote > REST oriented applications. > There has been some discussion on this list in the past, here is a summary > of the approaches I've heard: > > 1 Metadata within response content. > This works for HTML, but isn't suitable for unforgiving content like JPG, > GIF, PDF, MS-Word, schema-bound XML, etc. > For a custom app with your own content types, you could use a <meta> or > <head> element to provide the needed info. > Ideally, the metadata would be available via a HEAD method as well, and this > approach doesn't work with that. > > 2 Metadata within response headers > This is your proposal, to have something like Accept-POST and Accept-PUT > response headers for GET and HEAD. > > 3 Metadata in a separate resource known to original resource > 3.1 Identified by response content > The content can provide the location of the metadata, rather than the > metadata itself. Same problems as #1 (doesn't work for all content types, > etc.) > > 3.2 Identified by response header > This would be a header something like Meta-Location and would be availble > via GET or HEAD. > Putting metadata in a separate resource allows for content negotiation to > happen on the description of the resource, so we don't get stuck with not > enough metadata in the headers. > > 4 Metadata in a separate resource but unknown to original resource > This inverts the problem - you have the URL to a resource definition, but > you don't know what the resources are that it applies to. However, you could > explicitly list those resources, or provide a pattern that matches the URI > of the resources the defintion applies to. If you gather enough descriptions > you probably could do the lookup... > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com
Hi Folks, See here for a discussion of discovering a resource's metadata, and vice-versa: http://www.xfront.com/dist-reg/distributed-registry.html /Roger...
Roger L. Costello
costello@...
Jan 21, 2003 7:11 pm
Roger, I'm curious about the need for these extension headers you propose. Isn't that what the OPTIONS method is for? Shouldn't you be able to do an OPTIONS...
Roger, I'm curious about the need for these extension headers you propose. Isn't that what the OPTIONS method is for? Shouldn't you be able to do an OPTIONS...
... From: <jeffreywinter@...> ... that ... request ... way ... Huh. I thought I looked at OPTIONS and it wasn't appropriate... don't know what I was...
... Interesting idea. RFC2616 is incredibly vague about exactly how you use OPTIONS. It is so vague so as to be unusable as is. That being said, I like the...
Hi Jeff, I am not clear on what you are expecting the HTTP OPTIONS method to return. For example suppose that this is the URL to a Web service resource that...
Roger L. Costello
costello@...
Jan 21, 2003 9:09 pm
... Could you not return the link to the service in a "Location" header on the response? rfc2616 says: The Location response-header field is used to redirect...
From: "S. Mike Dierken" <mdierken@...> ... Hmm... When the RFC says the response is not cachable, I am wondering if they have proxies, etc. in mind....
... I guess that's the point of OPTIONS, I don't know exactly what I'd get back. If it's a WSDL, there are tools that can parse it directly; if it's a text...
... This brings up a question, can you do content negotiation when doing OPTIONS? That way you could support multiple file formats for describing web services....
According to the spec, yes: "The response body, if any, SHOULD also include information about the communication options. The format for such a body is not...
Hi Jeff, I don't have a lot of time, but I'll make a few, quick comments. 1. Consider a movie. Is it worth seeing? If Gene Siskel gives it a "two thumbs up",...
Roger L. Costello
costello@...
Jan 22, 2003 1:30 pm
... I think we are mixing two very separate concepts of metadata. One type of metadata describes the what or why of a resource. This class of metadata is...
... From: "Roger L. Costello" <costello@...> ... For some forms of metadata, you want the authoritative source to be the resource itself - like what the...
Hi Alex, ... I believe that you are missing my point. Let me quote David Jacobs: "Metadata about a web service goes beyond a WSDL file, XML Schemas and a ...
Roger L. Costello
costello@...
Jan 22, 2003 6:16 pm
Why not access all of the various functionality of a service by specifying different ACCEPT values on the request? So, if I want the service's response in XML...
Hi Mike, ... If I understand you correctly, you are saying that a Web service should have an "authoritative service description". I agree! The Meta-Location...
Roger L. Costello
costello@...
Jan 22, 2003 6:27 pm
MessageTrue, but I'm not seeing how this relates to my comments below... ... Seairth Jacobs seairth@... ... From: Jeffrey Winter To: Seairth Jacobs ;...
Sorry, what I meant was that if there was some concern that since OPTIONS can't be cached and it would be possible that the metadata could be out of date by...
... the ... are. ... should ... Instead of introducing a new header for this, couldn't you just stick with the standard OPTIONS method? If you have one...
MessageTrue. However, I feel that the caching limitation only applies to intermediaries. Otherwise, the verb would be practically useless. You could...
... It is only non-cacheable by default. Use cache-control to change that. The Web had a notion of external links, but nobody could agree on the HTTP syntax...
Ahh! That all makes sense. However, I don't know that I would agree that the added header would increase latency since it would be an optional header. The...
Hi Jeff, ... "standard OPTIONS method"? There is no such thing. Don't be under the illusion that you are using something "that already exists". You are ...
Roger L. Costello
costello@...
Jan 23, 2003 7:19 am
Roger, ... the ... is ... I completely agree that very, very few, if any, are using OPTIONS in this way currently; but the same could be said of the headers...
Roy, I noticed in your WAKA ApacheCon presentation that you discuss the ability to include metadata about the resource and representation along with the...
... Yes, it includes external links with role attributes. It also allows metadata to be interleaved with the response data, thus removing the issue regarding...
... There are two basic issues, the most fundamental of which is that the metadata should be a standalone resource with it's own URI so that all normal HTTP...
Having problems with message search?
Offline 
Send Email