Re: draft HTTP 209 draft spec review

On Fri, Apr 11, 2014 at 10:43 AM, Jeni Tennison <jeni@jenitennison.com> wrote:
> Yves,
>
> I found it hard to think of other good reasons for using HTTP 209 except for saving a round-trip. The “don’t change the URL bar” is a bit of a reach. If you can think of one, let me know.

For the URL bar case, one could give an example such as searching for,
say, Albert Einstein on dbpedia and being directed to the page about
him:
http://dbpedia.org/page/Albert_Einstein

However, if one wanted to link to (e.g., in order to describe Einstein
in RDF) or "bookmark" the person Albert Einstein, one should instead
use this URI which can be found in the hyperlink at the top of the
page:
http://dbpedia.org/resource/Albert_Einstein

>From a usability point of view, this can be confusing. One would
often, by mistake or through lack of knowledge about these things,
link to or bookmark the "page" rather than the "resource" URI. The
redirection to the Web page might itself be confusing, with quick
changes in the address bar without prior notification to the user, and
is also slower than responding with the Web page directly. (An HTML5
app that wanted to preserve the original, "resource" URI in the
address bar could use the history API for that purpose, by replacing
the "page" URI with the "resource" URI, but with further quick changes
in the address bar as a result.)

With HTTP 2NN, it is possible to consistently present a single URI to
the user. Additionally, avoiding the extra request and response
reduces latency, both for browser-based navigation and for Linked Data
applications that request RDF.

(While I'm not in the TAG, I'd very much appreciate a solution such as
HTTP 2NN and I do think retaining the original URI is an important
advantage, and in some ways more difficult to deal with in alternative
ways than the latency issue. Thanks in advance for considering my
suggestion for improving the spec!)

Best regards,
Erik


>
> I actually think the 303+200 definition is unhelpful for the general case. It sort of works for rel=describedby, but only when the originally requested resource is a non-information resource. But if you’re requesting an information resource and wanting to get its description, or its provenance, or a related package, then the original response could have been a 200. The real distinguishing feature is the inclusion of a Link with a relevant relation, followed by a request on that related resource.
>
> I’m happy to change the recommendation re Location/Content-Location.
>
> Jeni
>
> ------------------------------------------------------
> From: Yves Lafon ylafon@w3.org
> Reply: Yves Lafon ylafon@w3.org
> Date: 10 April 2014 at 23:29:57
> To: Jeni Tennison jeni@jenitennison.com
> Cc: www-tag@w3.org www-tag@w3.org
> Subject:  Re: draft HTTP 209 draft spec review
>
>> On Sat, 5 Apr 2014, Jeni Tennison wrote:
>>
>> > TAG members,
>> >
>> > As discussed during our face-to-face this last week, I have put together
>> > a draft review of the draft spec for the HTTP 209 status code, at:
>> >
>> > https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md
>> >
>> > I?d appreciate a second pair of eyes before we officially forward this
>> > on to Eric Prudhommeaux as a consensual TAG review.
>>
>> I would also be happy if the primary goal stated by the document was not
>> "saving one round trip", especially if we decide to use 209 for other
>> "related" use cases, as we discussed during the f2f.
>>
>> Thinking about it, 303+200 should be
>> 209, with a Location: equal to Content-Location:
>>
>> That leaves open definition of 209 where Location: is different from
>> Content-Location: and lead to a more generic definition of 209 which would
>> 303 + a body which about what was requested, but not the result of
>> dereferencing the URL present in Location:
>>
>>
>> --
>> Baroula que barouleras, au tiéu toujou t'entourneras.
>>
>> ~~Yves
>>
>>
>>
>>
>
> --
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Friday, 11 April 2014 13:24:07 UTC