Re: Filters as views (ISSUE-45)

> On 11 Feb 2016, at 23:41, Maik Riechert <maik.riechert@arcor.de> wrote:
> 
> 
> 
>> 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.

That's why I insist that the notion of representation/resource is relative. The resource "today's weather” has currently as representation “the weather of 12 February 2016”, which in turn is a resource in its own right that can be represented in HTML, JSON, etc. Depending on the viewpoint, the 12 Feb weather is either a representation or a resource.

So: no problem to do conneg on a page URI.

Ruben

> 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 Friday, 12 February 2016 08:59:27 UTC