Re: Headers vs Response Code for 2NN Contents Of Related

On 2014-09-27 13:46, Sandro Hawke wrote:
> We seem to be stalled in discussion of the 2NN Contents Of Related
> proposal [1]. I'd like to briefly summarize the concerns I've heard and
> provide summary responses. Then I'd like to sketch an alternative
> proposal which might be more widely acceptable. It has the particular
> advantage of not needing IETF consensus to go forward, since it just
> requires new headers, not a new response code.
>
> First, I think these are the main points in the discussion so far:
>
> Q. Why do you want a new response code?
>
> We have a community of Linked Data users, passing around RDF over HTTP
> connections, and this is something they want. I'm specifically
> representing the W3C Linked Data Platform (LDP) WG which wants it for
> paging, to avoid a roundtrip. Others have said it would be useful for
> them, including the W3C TAG which says it helps with their httpRange-14
> issue.
>
> Q. Why is one additional roundtrip so important?
>
> If you're getting 1000 pages, then obviously adding one roundtrip is a
> trivial additional cost, but we expect the common behavior to be just
> looking at the first page. When you look at search results, do you go
> through every page? No, the response was, "There are a lot of results,
> here are some", and that's often enough, especially if they're ordered
> in some useful way. In this case of just looking at a small first page,
> saving the roundtrip could nearly double the speed.
>
> Q. These interactions wont always make full use of caching.
>
> True, not with the current cache architecture, they wont. We have some
> ideas for how to make caching work much better for Linked Data
> applications, but that can be handled separately.
>
> Q. Why not use Range, with a new type of units?
>
> That's not the way WebApps are usually written. There are a lot of
> details that would have to be figured out which are already figured out
> for next/prev paging, and that's what the developers seem to want. Plus,
> since the bar for new range units is IETF consensus, we're not
> optimistic that we'd be able to move forward even if we figured it all out.
>
> Q. Why not use 200 OK + Content Location?
>
> 200+CL is defined as returning a representation of the requested
> resource, but in next/prev paging, each of those pages is conceptualized
> as its own resource. Logically, something can't be the same resource as
> its own first page. In practical terms, if a server used 200+CL to
> return just the first page, how would the client know it had only been
> sent the first few triples (instead of all of them, as usual)? The
> Content-Location header is already used is con-neg so it can't also
> carry this information.
>
> Q. Why not use 200+Link?
>
> It's true that in LDP paging there are Link headers that would tell the
> client it got the first page instead of the whole resource, but then
> we've still misused 200 OK and are sending a representation of a
> different resource. We'd have to carefully avoid caching, and it's
> unclear what other things might break by having links change the semantics.
>
>
> This does however lead to my current proposal, which is that we use a
> new header (really a pair of headers) for this purpose. The details
> could be tweaked, but it would be something like this:
>
> In general, the purpose and data flow and caching rules are the same as
> in the 2NN proposal [1]. The syntax differs as follows:
>
> (1) the client signals that it implements and wants to use this
> mechanism by sending something like
>
> Please-Follow-Redirects: 303
>
> instead of
>
> Prefer: contents-of-related
>
> The values for this new header would be 3xx codes. Repeated values would
> mean that multiple kinds of redirects should be followed.
 > ...

Why don't you just make it:

   Prefer: retrieve-contents-of-303-target

(with a more suitable name...)

?

Best regards, Julian

Received on Saturday, 27 September 2014 21:38:46 UTC