W3C home > Mailing lists > Public > www-tag@w3.org > July 2012

RE: Changing representations

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>
Message-ID: <1343418426.2725.50784.camel@dbooth-laptop>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 July 2012 19:47:37 GMT