Re: Filters as views (ISSUE-45)

Am 11.02.2016 um 18:48 schrieb Ruben Verborgh:
> Hi Maik,
>
>> This should only be used if you want to point to a concrete representation when directly returning an entity response following some kind of content negotiation.
> The spec seems to agree with you:
>
>>> For a response to a GET or HEAD request, [Content-Location] is an indication
>>>        that the effective request URI refers to a resource that is
>>>        subject to content negotiation and the Content-Location
>>>        field-value is a more specific identifier for the selected
>>>        representation.
>>>
> —https://tools.ietf.org/html/rfc7231#section-3.1.4.2
>
> That said, why can a page not be a content-negotiated version,
> if the server has determined the client would not like long pages?
> A representation can only present part of a resource;
> in this case, the part just gets an identifier.
I guess you could see it that way, even if it's a little bit stretched 
maybe. But then you would explicitly say that a page is a representation 
and not a resource, which would mean that you couldn't do content 
negotiation on that page, and I think this is not what we want. Apart 
from that, is Content-Location supposed to change interpretation for GET 
requests? It seems like it is merely a way to get a non-negotiated URL 
from which the exact same response body can be retrieved at a later 
time. But it doesn't automatically assign that URL to the request URL. I 
would regard Content-Location always as optional for GET requests, and 
in that case (leaving out Content-Location), if you serve out the first 
page at /collection then a client would not know that this is actually 
the first page. Sure, it would see that the collection has a view but it 
can't create the connection that this view is actually what the resource is.

Let me know what you think, maybe I'm wrong here.

Cheers
Maik

Received on Thursday, 11 February 2016 22:41:54 UTC