- From: David Booth <david@dbooth.org>
- Date: Thu, 26 Jul 2012 11:16:02 -0400
- To: Danny Ayers <danny.ayers@gmail.com>
- Cc: W3C TAG <www-tag@w3.org>
Hi Danny, On Thu, 2012-07-26 at 11:39 +0200, Danny Ayers wrote: > I've struggled with this myself, on seeing the same question appear on > another list I think it's worth posing. I'd appreciate clarification. > > Server-side you have a named resource. You PUT something there in a > given media type, what expectations have you over other media types? > My feeling was it doesn't matter, as long as the HTTP contract, any > subsequent GET will give something appropriate. Hopefully the change > percolates. But although that makes sense, it's kinda vague. The > interpretation I saw by this guy on a list, trying to follow the spec > properly, was like there were different buckets hanging of the > resource, you push some json, the json bucket changes. Does that > influence the other buckets? > > Might have to dig Roy up, but clarification on this would help. I'm not a TAG member, but I'll give my 2 cents. If I've understood correctly, you have described two competing service models for a given URI: (a) one PUT affects all GET media types; versus (b) one PUT per GET media type. Both seem perfectly valid and seem to me to fill different use cases. In either model the URI identifies a "generic resource" http://www.w3.org/DesignIssues/Generic.html http://www.w3.org/2006/gen/ont because different media types may be served from the same URI. Thus, if you are using the one-PUT-affects-all-GET-media-types model, then the server is responsible for maintaining semantic consistency between the representations, whereas if you use the one-PUT-per-GET-media-type model then there is an expectation that the client is responsible for maintaining that semantic consistency, which of course is more error prone, but may be better for some use cases. Also relevant . . . RFC2616 discussion of PUT says: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 [[ A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server. ]] Content-Location header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 BTW, when a generic resource is used, it is also good to provide a specific URI for each variant. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Thursday, 26 July 2012 15:16:37 UTC