Re: By way of example.

>
>In one of my implementations, our service doc is always available
>through the same uri..
>
>  http://example.org/oa/service/atom/introspection
>
>The content of the returned document varies depending on the
>authentication credentials of the caller.
>

My point exactly.  You have multiple resources, one for each user, sharing 
the same address with no distinction between them, which is _exactly_ why it 
is good practice to return a distinguishing Content-Location to the client.

Each of those resources needs its own URI if you want to access them in a 
RESTful fashion instead of an RPC fashion, whether you return that URI in a 
Content-Location is indeed optional but the point is it's something you 
should be able to do.  If you can't you have, by definition, a URI collision.

-EJB

>
>The document is served over
>an SSL connection.  We're not returning a Content-Location header
>because there's no need to return one.
>
>Where's the collision?
>
>- James
>
>Eric J. Bowman wrote:
>>> I beg to disapprove. You are making a mistake because you expect several 
>>> protocols to play through the same interface (GET, PUT, POST, etc.) with 
>>> a single URI.
>>>
>> 
>> http://example.com/service
>> 
>> This is a URI collision even if the only thing it serves up is .atomsrv, 
>> even 
>> if I expect only one protocol (APP) to dereference this.
>> 
>> If the returned Content-Location looks like /service for all users, this is 
>> clearly a URI collision.  My solution, returning userid.atomsrv, is simply 
>> another form of the same URI collision inherent in the spec, no matter how 
>> radically various implementations diverge.  You may not like my 
>> implementation but I guarantee you you cannot avoid the URI collision in 
>> yours, either, unless you restrict to one user.  It's what the spec calls 
>> for.
>> 
>> -EJB
>> 
>> 
>> 
>> 
>