RE: Representation consistency and content negotiation

I would offer a slightly different perspective than Elliotte.

> From: Elliotte Harold
> 
> Drummond Reed wrote:
> 
> > #1: Requestor-dependent representations. Many sites return different
> > versions of a web page based on who is requesting it, such 
> > as a personalized
> > homepage. How does that fit with the rule? Is the cookie 
> > used to identify
> > the requestor considered implicitly part of the URI of the resource?
> 
> IMHO, that's a violation of the web architecture. The cookie 
> is not part 
> of the URI and should not be treated as such. 
> http://www.example.com/joesmith and 
> http://www.example.com/janedoe can 
> be two different resources. http://www.example.com/ cannot be.

Although I agree that the cookie definitely is NOT part of the URI, and it would be reasonable to have distinct URIs for Joe and Jane's customized pages, this does not mean that there should not also be a URI for the generic page that is parameterized by user when the user logs in.  The basic web architectural principle is that important resources should have URIs, and in this example *all* of these resources -- the generic and the user-specific -- are arguably important resources and thus candidates for having URIs.

> 
> > #2: A related use case is requestor-dependent access 
> > control. For example is
> > it okay for a request to the same URI to return a full web 
> > page for one
> > fully-authorized requester and a redacted version to another
> > less-fully-authorized requestor?
> 
> Less problematic, but still questionable, IMHO.

My answer: Yes it is okay.  HOWEVER, you run the risk of confusing users about which resource is being denoted by the URI if the page does not clearly indicate that it has been redacted for viewing by a particular user.  For example, suppose each redacted version *also* has a URI, and there is also a URI for the completely un-redacted version:

http://www.example.com/ -- Generic resource that will be redacted depending on user.
http://www.example.com/joesmith -- Specific resource as viewed by Joe.
http://www.example.com/janedoe -- Specific resource as viewed by Jane.
http://www.example.com/unredacted -- Completely unredacted version.

When Joe views http://www.example.com/ he may think he is viewing the the unredacted version when he is really viewing the redacted-for-joe version.
 
> 
> > #3: Content type-dependent representations. Can the view of 
> > a resource
> > returned from a URI as expressed by one content-type differ 
> > from the view
> > expressed by a different content-type? For example, from 
> > the URI for a
> > person's web calender, could a request for text/calendar 
> > the ical content
> > type) produce one response, while a request from the same URI for
> > text/free-busy (a fictional free-busy content type) produce another?
> 
> Not really. Fundamentally the same information shoudl be 
> present in both representations.

I agree that this is the spirit of RFC2616 section 12 "Content Negotiation", as evidenced by phrases like '"best available" entity corresponding to the request", though it isn't clear that doing so is absolutely required.

> 
> Of course, all these distinctions are fuzzy. Putting a "hello John 
> Smith" or "Hello Jane Doe" at the top of the page really 
> isn't all that 
> significant. However a page that shows John Doe's monthly credit card 
> statement is radically different from a page that shows Jane Smith's 
> statement, and those pages really need to have two different 
> URLs. They 
> are not each merely restricted views of the complete set of 
> all credit card statements.

Yes, John's monthly credit card statement and the generic, credit-card-statement-parameterized-by-user are distinct resources, and are both candidates for distinct URIs.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.

Received on Tuesday, 13 January 2009 14:29:46 UTC