- From: David Booth <david@dbooth.org>
- Date: Fri, 27 Jul 2012 15:47:06 -0400
- To: Larry Masinter <masinter@adobe.com>
- Cc: Danny Ayers <danny.ayers@gmail.com>, W3C TAG <www-tag@w3.org>
On Fri, 2012-07-27 at 12:04 -0700, Larry Masinter wrote: > > 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. > > Think of the possibility where the server can convert on the fly > between multiple representations, based on the "Accept" header. > In this case, there are multiple representations (anything that can be > converted to) but only one resource (which serves the 'original' if > its format is acceptable, otherwise something converted). > > That use case was forefront in my mind when we were adding > content-negotiation to HTTP. > > The GET media types are all just shadows of the original. "PUT" says > "replace this resource with some resource based on the included > representation". > > I don't think (b) is "perfectly valid" in this use case. But (a) is. Agreed. That's the use case for (a). > I can't think of any use case where the converse is true. A use case for (b) is when it is expensive for the server to generate the different media types, and the server is willing to trust the client to maintain semantic consistency between the media types. Certainly this is a very rare use case, but nonetheless valid. If we are just giving "which approach should I normally use" advice, I would say definitely (a) if possible, as it's much safer and more user friendly. -- 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 Friday, 27 July 2012 19:47:36 UTC