On Jul 20, 2005, at 5:18 AM, Nic Ferrier wrote:

>> Resources are concepts. If I have separate concepts of "bank
>> statement in PDF" and "bank statement in HTML", then two separate
>> URIs (one ending in .pdf and one ending in .html) make the most
>> conceptual sense.
>
> I disagree because cool URIs don't change.
>
> If you have separate concepts of "bank statement in PDF" and "bank
> statement in HTML" then I think you're quite unusual. I think of my
> bank statement as my bank statement and I think most people do.

No, there are three resources. One is your generic bank statement.
Second is your bank statement in PDF. Third is your bank statement
in HTML. Three distinct resources calls for three distinct URIs,
even if one of them is just a negotiation point for the rest.

> Resources should not be tied to representations. The reason for this
> is that the resource that identifies my bank statement should always
> be the same. When I'm seventy (if I still have the same bank account
> which is pretty unlikely I have to say) I'd expect my bank statement
> URI to be the same.

That is true for some interactions, but not all. Authoring, for
example, should always be performed on a specific URI that is
dependent on the format, since that allows you to author many
different representations for the more generic URI at the same
time without having to rely on server gymnastics to understand
what resource is being authored.

> Ok. So it comes down to whether you accept that Cool URIs Don't
> Change is part of REST. I can't remember if there's anything in Roy's
> original paper about this. But since this stuff is quite clear in the
> HTTP spec I believe that cool URIs don't change. /8->

Those are orthogonal issues. The fact that you have one URI that
is generic does not in any way limit the number of less generic
URIs that are also used and available within an application.
All URIs are important.

REST is designed so that URI references don't need to change,
which is the principle behind Tim's "cool URIs don't change"
comments. That is the final bit of

This abstract definition of a resource enables key features
of the Web architecture. First, it provides generality by
encompassing many sources of information without artificially
distinguishing them by type or implementation. Second, it
allows late binding of the reference to a representation,
enabling content negotiation to take place based on
characteristics of the request. Finally, it allows an author
to reference the concept rather than some singular
representation of that concept, thus removing the need to
change all existing links whenever the representation
changes (assuming the author used the right identifier).

Using the right identifier requires that identifiers be available
for everything one might want to identify, including each individual
resource that makes up the value set of some "cool URI" resource.

....Roy