Redirection vs. Content-location (was Re: Filters as views (ISSUE-45))

(I propose to change the thread subject, as this interesting topic is
sidetracking from the original one)

On Fri, Feb 12, 2016 at 9:58 AM, Ruben Verborgh <ruben.verborgh@ugent.be>
wrote:

>
> > 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.
>

+1

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.
>

There was a debate in the LD community a few years back, where Ian Davis
proposed to use Content-Location as a cheaper alternative to 303 redirect.

https://web.archive.org/web/20110510131329/http://iand.posterous.com/is-303-really-necessary

There was some reactions there :
https://groups.google.com/forum/#!topic/thosch/zLk-QZd3Ec0[1-25]

Overall, people seemed reluctant to this solution, in part because the
interpretation of Content-Location does not make consensus among browser
vendors:

http://jigsaw.w3.org/HTTP/CL/

Personally, I think this is an elegant alternative to redirection, although
I don't think that Hydra should mandate one or the other.

pa



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