draft-nottingham-http-link-header-05: a question and an experimental implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

draft-nottingham-http-link-header-05: a question and an experimental implementation

Mike Burrows
I have a question on draft-nottingham-http-link-header-05: is there an
agreed mechanism for clients to indicate whether they want link
headers, the equivalent html/xml elements, or neither?  It seems
wasteful to generate redundant or unneeded data, especially while
client support for the headers is not widespread.   Apologies if this
has been covered previously (I did review the April-June archive).

Meanwhile, you may be interested in an experimental implementation of
link headers (&/or elements) for Ruby on Rails, generating them from
metadata constructed from the application's routing config.  Please
drop me a line if you'd like to play with it.  There is a Python
library too but it lacks the server framework integration.

I went with the hash URI approach [1] to identifying extension
relation types, with the fragment pointing inside the metadata
obtainable (in multiple formats) via the "describedby" links.  See for
example the last two links below:

    Link: <http://example.com/users/dojo>; rel="self"; type="user",
          <http://example.com/described_routes/user>;
rel="describedby"; type="ResourceTemplate",
          <http://example.com/described_routes/user?user_id=dojo>;
rel="describedby"; type="ResourceTemplate",
          <http://example.com/users>; rel="up"; type="users",
          <http://example.com/users/dojo/edit>; rel="edit";
rel="http://example.com/described_routes/user#edit"; type="edit_user",
          <http://example.com/users/dojo/articles>;
rel="http://example.com/described_routes/user#articles";
type="user_articles"

If I interpret the spec correctly, there is no strong guidance on the
use of the "type" attribute.  I hope that my usage here seems
reasonable.

    [1] http://www.w3.org/TR/cooluris/#hashuri

Regards,

Mike
[hidden email]
http://positiveincline.com
http://twitter.com/asplake

Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Mike Burrows
Re my last paragraph below, I hadn't checked RFC 4287 for a
description of the "type" attribute.  Newbie error, apologies.

With that out of the way, what's the thinking on the duplication of
link elements and link headers?  Are there mechanisms for UAs to
indicate which they prefer?  I've been through a year's worth of
archive now and didn't find this addressed anywhere.

Thanks,
Mike

2009/6/19 Michael Burrows <[hidden email]>:

> I have a question on draft-nottingham-http-link-header-05: is there an
> agreed mechanism for clients to indicate whether they want link
> headers, the equivalent html/xml elements, or neither?  It seems
> wasteful to generate redundant or unneeded data, especially while
> client support for the headers is not widespread.   Apologies if this
> has been covered previously (I did review the April-June archive).
>
> Meanwhile, you may be interested in an experimental implementation of
> link headers (&/or elements) for Ruby on Rails, generating them from
> metadata constructed from the application's routing config.  Please
> drop me a line if you'd like to play with it.  There is a Python
> library too but it lacks the server framework integration.
>
> I went with the hash URI approach [1] to identifying extension
> relation types, with the fragment pointing inside the metadata
> obtainable (in multiple formats) via the "describedby" links.  See for
> example the last two links below:
>
>    Link: <http://example.com/users/dojo>; rel="self"; type="user",
>          <http://example.com/described_routes/user>;
> rel="describedby"; type="ResourceTemplate",
>          <http://example.com/described_routes/user?user_id=dojo>;
> rel="describedby"; type="ResourceTemplate",
>          <http://example.com/users>; rel="up"; type="users",
>          <http://example.com/users/dojo/edit>; rel="edit";
> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>          <http://example.com/users/dojo/articles>;
> rel="http://example.com/described_routes/user#articles";
> type="user_articles"
>
> If I interpret the spec correctly, there is no strong guidance on the
> use of the "type" attribute.  I hope that my usage here seems
> reasonable.
>
>    [1] http://www.w3.org/TR/cooluris/#hashuri
>
> Regards,
>
> Mike
> [hidden email]
> http://positiveincline.com
> http://twitter.com/asplake
>

Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Phil Archer-3
Hi Michael,


Michael Burrows wrote:
> Re my last paragraph below, I hadn't checked RFC 4287 for a
> description of the "type" attribute.  Newbie error, apologies.
>
> With that out of the way, what's the thinking on the duplication of
> link elements and link headers?  Are there mechanisms for UAs to
> indicate which they prefer?  I've been through a year's worth of
> archive now and didn't find this addressed anywhere.

I'm not aware of any such mechanisms but it's a point that I've heard
raised informally. Adding in a bunch of links in the HTTP response to
every request when they're not required is the kind of thing that gets
server infrastructure engineers very upset.

However, I don't think there's a need to invent anything new here.
Cookies could easily be set that indicated that Links had already been
consumed by a given browser. Of course, that only applies on the second
and subsequent requests, not the first one, so it doesn't answer all
your point, but it gets pretty close?

Opera and FF both implement HTTP Link (see [1] for example) but Chrome,
Safari and IE don't. It's pretty easy therefore to configure a server to
include HTTP Link for those browsers based simply on the UA string and
put in the HTML link elements for the others? Again, not a complete
solution, I know, but a practical way forward?

Cheers

Phil.

[1] http://www.fosi.org/archive/httplinktest/


> 2009/6/19 Michael Burrows <[hidden email]>:
>> I have a question on draft-nottingham-http-link-header-05: is there an
>> agreed mechanism for clients to indicate whether they want link
>> headers, the equivalent html/xml elements, or neither?  It seems
>> wasteful to generate redundant or unneeded data, especially while
>> client support for the headers is not widespread.   Apologies if this
>> has been covered previously (I did review the April-June archive).
>>
>> Meanwhile, you may be interested in an experimental implementation of
>> link headers (&/or elements) for Ruby on Rails, generating them from
>> metadata constructed from the application's routing config.  Please
>> drop me a line if you'd like to play with it.  There is a Python
>> library too but it lacks the server framework integration.
>>
>> I went with the hash URI approach [1] to identifying extension
>> relation types, with the fragment pointing inside the metadata
>> obtainable (in multiple formats) via the "describedby" links.  See for
>> example the last two links below:
>>
>>    Link: <http://example.com/users/dojo>; rel="self"; type="user",
>>          <http://example.com/described_routes/user>;
>> rel="describedby"; type="ResourceTemplate",
>>          <http://example.com/described_routes/user?user_id=dojo>;
>> rel="describedby"; type="ResourceTemplate",
>>          <http://example.com/users>; rel="up"; type="users",
>>          <http://example.com/users/dojo/edit>; rel="edit";
>> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>>          <http://example.com/users/dojo/articles>;
>> rel="http://example.com/described_routes/user#articles";
>> type="user_articles"
>>
>> If I interpret the spec correctly, there is no strong guidance on the
>> use of the "type" attribute.  I hope that my usage here seems
>> reasonable.
>>
>>    [1] http://www.w3.org/TR/cooluris/#hashuri
>>
>> Regards,
>>
>> Mike
>> [hidden email]
>> http://positiveincline.com
>> http://twitter.com/asplake
>>
>
>

--

Phil Archer
http://philarcher.org/

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |      www.w3.org/Mobile

Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Michael Burrows-2
Thanks Phil, that seems reasonable enough.

For the record (expanded somewhat in [1]), I went with "role" to fix
my erroneous use of "type" and its values are URIs now.  Very much
along the lines of Tim BL's Metadata Architecture note [2] it
generates globally unique identifiers not only for relationships but
also their source and target entities in a logical ER view of the
application, the entities corresponding to the application's templated
"routes".  Moreover those identifiers point ("hash fragment" style)
inside metadata documents.

    [1] http://positiveincline.com/?p=392
    [2] http://www.w3.org/DesignIssues/Metadata.html

Regards,
Mike


2009/6/23 Phil Archer <[hidden email]>:

> Hi Michael,
>
>
> Michael Burrows wrote:
>>
>> Re my last paragraph below, I hadn't checked RFC 4287 for a
>> description of the "type" attribute.  Newbie error, apologies.
>>
>> With that out of the way, what's the thinking on the duplication of
>> link elements and link headers?  Are there mechanisms for UAs to
>> indicate which they prefer?  I've been through a year's worth of
>> archive now and didn't find this addressed anywhere.
>
> I'm not aware of any such mechanisms but it's a point that I've heard raised
> informally. Adding in a bunch of links in the HTTP response to every request
> when they're not required is the kind of thing that gets server
> infrastructure engineers very upset.
>
> However, I don't think there's a need to invent anything new here. Cookies
> could easily be set that indicated that Links had already been consumed by a
> given browser. Of course, that only applies on the second and subsequent
> requests, not the first one, so it doesn't answer all your point, but it
> gets pretty close?
>
> Opera and FF both implement HTTP Link (see [1] for example) but Chrome,
> Safari and IE don't. It's pretty easy therefore to configure a server to
> include HTTP Link for those browsers based simply on the UA string and put
> in the HTML link elements for the others? Again, not a complete solution, I
> know, but a practical way forward?
>
> Cheers
>
> Phil.
>
> [1] http://www.fosi.org/archive/httplinktest/
>
>
>> 2009/6/19 Michael Burrows <[hidden email]>:
>>>
>>> I have a question on draft-nottingham-http-link-header-05: is there an
>>> agreed mechanism for clients to indicate whether they want link
>>> headers, the equivalent html/xml elements, or neither?  It seems
>>> wasteful to generate redundant or unneeded data, especially while
>>> client support for the headers is not widespread.   Apologies if this
>>> has been covered previously (I did review the April-June archive).
>>>
>>> Meanwhile, you may be interested in an experimental implementation of
>>> link headers (&/or elements) for Ruby on Rails, generating them from
>>> metadata constructed from the application's routing config.  Please
>>> drop me a line if you'd like to play with it.  There is a Python
>>> library too but it lacks the server framework integration.
>>>
>>> I went with the hash URI approach [1] to identifying extension
>>> relation types, with the fragment pointing inside the metadata
>>> obtainable (in multiple formats) via the "describedby" links.  See for
>>> example the last two links below:
>>>
>>>   Link: <http://example.com/users/dojo>; rel="self"; type="user",
>>>         <http://example.com/described_routes/user>;
>>> rel="describedby"; type="ResourceTemplate",
>>>         <http://example.com/described_routes/user?user_id=dojo>;
>>> rel="describedby"; type="ResourceTemplate",
>>>         <http://example.com/users>; rel="up"; type="users",
>>>         <http://example.com/users/dojo/edit>; rel="edit";
>>> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>>>         <http://example.com/users/dojo/articles>;
>>> rel="http://example.com/described_routes/user#articles";
>>> type="user_articles"
>>>
>>> If I interpret the spec correctly, there is no strong guidance on the
>>> use of the "type" attribute.  I hope that my usage here seems
>>> reasonable.
>>>
>>>   [1] http://www.w3.org/TR/cooluris/#hashuri
>>>
>>> Regards,
>>>
>>> Mike
>>> [hidden email]
>>> http://positiveincline.com
>>> http://twitter.com/asplake
>>>
>>
>>
>
> --
>
> Phil Archer
> http://philarcher.org/
>
> i-sieve technologies                |      W3C Mobile Web Initiative
> Beyond Impressions                  |      www.w3.org/Mobile
>
>

Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Phil Archer-3
Hi Mike,

That makes sense and, as I guess you know well, there's a module on
'role' for XHTML [1].

With all those links, perhaps with additional type="MIME-type"
attributes, I quite see why you're concerned about shipping so many
bytes with every request.

You might want to take a look at Mark Nottingham and Eran Hammer-Lahav's
work in site-meta and discovery at [2] and [3]. These are beginning to
look a little out of date now but AIUI you'll be able to put all your
links in the well known location to end all well known locations
(actually, I think they're now gunning for /well-known) and then put all
your links in a text file at that location.

Phil.

[1] http://www.w3.org/TR/xhtml-role/
[2] http://www.mnot.net/drafts/draft-nottingham-site-meta-01.txt
[2] http://www.ietf.org/internet-drafts/draft-hammer-discovery-03.txt

Michael Burrows wrote:

> Thanks Phil, that seems reasonable enough.
>
> For the record (expanded somewhat in [1]), I went with "role" to fix
> my erroneous use of "type" and its values are URIs now.  Very much
> along the lines of Tim BL's Metadata Architecture note [2] it
> generates globally unique identifiers not only for relationships but
> also their source and target entities in a logical ER view of the
> application, the entities corresponding to the application's templated
> "routes".  Moreover those identifiers point ("hash fragment" style)
> inside metadata documents.
>
>     [1] http://positiveincline.com/?p=392
>     [2] http://www.w3.org/DesignIssues/Metadata.html
>
> Regards,
> Mike
>
>
> 2009/6/23 Phil Archer <[hidden email]>:
>> Hi Michael,
>>
>>
>> Michael Burrows wrote:
>>> Re my last paragraph below, I hadn't checked RFC 4287 for a
>>> description of the "type" attribute.  Newbie error, apologies.
>>>
>>> With that out of the way, what's the thinking on the duplication of
>>> link elements and link headers?  Are there mechanisms for UAs to
>>> indicate which they prefer?  I've been through a year's worth of
>>> archive now and didn't find this addressed anywhere.
>> I'm not aware of any such mechanisms but it's a point that I've heard raised
>> informally. Adding in a bunch of links in the HTTP response to every request
>> when they're not required is the kind of thing that gets server
>> infrastructure engineers very upset.
>>
>> However, I don't think there's a need to invent anything new here. Cookies
>> could easily be set that indicated that Links had already been consumed by a
>> given browser. Of course, that only applies on the second and subsequent
>> requests, not the first one, so it doesn't answer all your point, but it
>> gets pretty close?
>>
>> Opera and FF both implement HTTP Link (see [1] for example) but Chrome,
>> Safari and IE don't. It's pretty easy therefore to configure a server to
>> include HTTP Link for those browsers based simply on the UA string and put
>> in the HTML link elements for the others? Again, not a complete solution, I
>> know, but a practical way forward?
>>
>> Cheers
>>
>> Phil.
>>
>> [1] http://www.fosi.org/archive/httplinktest/
>>
>>
>>> 2009/6/19 Michael Burrows <[hidden email]>:
>>>> I have a question on draft-nottingham-http-link-header-05: is there an
>>>> agreed mechanism for clients to indicate whether they want link
>>>> headers, the equivalent html/xml elements, or neither?  It seems
>>>> wasteful to generate redundant or unneeded data, especially while
>>>> client support for the headers is not widespread.   Apologies if this
>>>> has been covered previously (I did review the April-June archive).
>>>>
>>>> Meanwhile, you may be interested in an experimental implementation of
>>>> link headers (&/or elements) for Ruby on Rails, generating them from
>>>> metadata constructed from the application's routing config.  Please
>>>> drop me a line if you'd like to play with it.  There is a Python
>>>> library too but it lacks the server framework integration.
>>>>
>>>> I went with the hash URI approach [1] to identifying extension
>>>> relation types, with the fragment pointing inside the metadata
>>>> obtainable (in multiple formats) via the "describedby" links.  See for
>>>> example the last two links below:
>>>>
>>>>   Link: <http://example.com/users/dojo>; rel="self"; type="user",
>>>>         <http://example.com/described_routes/user>;
>>>> rel="describedby"; type="ResourceTemplate",
>>>>         <http://example.com/described_routes/user?user_id=dojo>;
>>>> rel="describedby"; type="ResourceTemplate",
>>>>         <http://example.com/users>; rel="up"; type="users",
>>>>         <http://example.com/users/dojo/edit>; rel="edit";
>>>> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>>>>         <http://example.com/users/dojo/articles>;
>>>> rel="http://example.com/described_routes/user#articles";
>>>> type="user_articles"
>>>>
>>>> If I interpret the spec correctly, there is no strong guidance on the
>>>> use of the "type" attribute.  I hope that my usage here seems
>>>> reasonable.
>>>>
>>>>   [1] http://www.w3.org/TR/cooluris/#hashuri
>>>>
>>>> Regards,
>>>>
>>>> Mike
>>>> [hidden email]
>>>> http://positiveincline.com
>>>> http://twitter.com/asplake
>>>>
>>>

--

Phil Archer
http://philarcher.org/

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |      www.w3.org/Mobile

Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Michael Burrows-2

Thanks, I'll do that.  I was in contact with Eran some time back (before I had anything very concrete) in the hope that everything I'm doing was done already.  It does still seem that I'm breaking some new ground, though there's back-tracking to be done every time it transpires that I've overlooked some previous work.  That's the price of trying to do the right thing I guess!


2009/6/25 Phil Archer <[hidden email]>
Hi Mike,

That makes sense and, as I guess you know well, there's a module on 'role' for XHTML [1].

With all those links, perhaps with additional type="MIME-type" attributes, I quite see why you're concerned about shipping so many bytes with every request.

You might want to take a look at Mark Nottingham and Eran Hammer-Lahav's work in site-meta and discovery at [2] and [3]. These are beginning to look a little out of date now but AIUI you'll be able to put all your links in the well known location to end all well known locations (actually, I think they're now gunning for /well-known) and then put all your links in a text file at that location.

Phil.

[1] http://www.w3.org/TR/xhtml-role/
[2] http://www.mnot.net/drafts/draft-nottingham-site-meta-01.txt
[2] http://www.ietf.org/internet-drafts/draft-hammer-discovery-03.txt


Michael Burrows wrote:
Thanks Phil, that seems reasonable enough.

For the record (expanded somewhat in [1]), I went with "role" to fix
my erroneous use of "type" and its values are URIs now.  Very much
along the lines of Tim BL's Metadata Architecture note [2] it
generates globally unique identifiers not only for relationships but
also their source and target entities in a logical ER view of the
application, the entities corresponding to the application's templated
"routes".  Moreover those identifiers point ("hash fragment" style)
inside metadata documents.

   [1] http://positiveincline.com/?p=392
   [2] http://www.w3.org/DesignIssues/Metadata.html

Regards,
Mike


2009/6/23 Phil Archer <[hidden email]>:
Hi Michael,


Michael Burrows wrote:
Re my last paragraph below, I hadn't checked RFC 4287 for a
description of the "type" attribute.  Newbie error, apologies.

With that out of the way, what's the thinking on the duplication of
link elements and link headers?  Are there mechanisms for UAs to
indicate which they prefer?  I've been through a year's worth of
archive now and didn't find this addressed anywhere.
I'm not aware of any such mechanisms but it's a point that I've heard raised
informally. Adding in a bunch of links in the HTTP response to every request
when they're not required is the kind of thing that gets server
infrastructure engineers very upset.

However, I don't think there's a need to invent anything new here. Cookies
could easily be set that indicated that Links had already been consumed by a
given browser. Of course, that only applies on the second and subsequent
requests, not the first one, so it doesn't answer all your point, but it
gets pretty close?

Opera and FF both implement HTTP Link (see [1] for example) but Chrome,
Safari and IE don't. It's pretty easy therefore to configure a server to
include HTTP Link for those browsers based simply on the UA string and put
in the HTML link elements for the others? Again, not a complete solution, I
know, but a practical way forward?

Cheers

Phil.

[1] http://www.fosi.org/archive/httplinktest/


2009/6/19 Michael Burrows <[hidden email]>:
I have a question on draft-nottingham-http-link-header-05: is there an
agreed mechanism for clients to indicate whether they want link
headers, the equivalent html/xml elements, or neither?  It seems
wasteful to generate redundant or unneeded data, especially while
client support for the headers is not widespread.   Apologies if this
has been covered previously (I did review the April-June archive).

Meanwhile, you may be interested in an experimental implementation of
link headers (&/or elements) for Ruby on Rails, generating them from
metadata constructed from the application's routing config.  Please
drop me a line if you'd like to play with it.  There is a Python
library too but it lacks the server framework integration.

I went with the hash URI approach [1] to identifying extension
relation types, with the fragment pointing inside the metadata
obtainable (in multiple formats) via the "describedby" links.  See for
example the last two links below:

 Link: <http://example.com/users/dojo>; rel="self"; type="user",
       <http://example.com/described_routes/user>;
rel="describedby"; type="ResourceTemplate",
       <http://example.com/described_routes/user?user_id=dojo>;
rel="describedby"; type="ResourceTemplate",
       <http://example.com/users>; rel="up"; type="users",
       <http://example.com/users/dojo/edit>; rel="edit";
rel="http://example.com/described_routes/user#edit"; type="edit_user",
       <http://example.com/users/dojo/articles>;
rel="http://example.com/described_routes/user#articles";
type="user_articles"

If I interpret the spec correctly, there is no strong guidance on the
use of the "type" attribute.  I hope that my usage here seems
reasonable.

 [1] http://www.w3.org/TR/cooluris/#hashuri

Regards,

Mike
[hidden email]
http://positiveincline.com
http://twitter.com/asplake



--

Phil Archer
http://philarcher.org/

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |      www.w3.org/Mobile


Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Mark Nottingham-4
In reply to this post by Phil Archer-3
The cookie strategy (or anything like it) isn't good for caching or  
scaling.

I think -- as in many things -- this requires a judgement call by the  
author. If you're slinging around hundreds of links on every response,  
there's a good chance that you're doing something wrong; odds are that  
most of the links will be irrelevant to most use cases. Refactoring  
into separate representations, etc. makes sense here.

In this way, it's no different to deciding what is at the other end of  
a URL; too fine-grained, and it's not useful, but too coarse-grained  
and you're giving too much information and overloading the  
infrastructure. Of course, what the infrastructure can take changes  
over time too.

Cheers,


On 23/06/2009, at 7:11 PM, Phil Archer wrote:

> Hi Michael,
>
>
> Michael Burrows wrote:
>> Re my last paragraph below, I hadn't checked RFC 4287 for a
>> description of the "type" attribute.  Newbie error, apologies.
>> With that out of the way, what's the thinking on the duplication of
>> link elements and link headers?  Are there mechanisms for UAs to
>> indicate which they prefer?  I've been through a year's worth of
>> archive now and didn't find this addressed anywhere.
>
> I'm not aware of any such mechanisms but it's a point that I've  
> heard raised informally. Adding in a bunch of links in the HTTP  
> response to every request when they're not required is the kind of  
> thing that gets server infrastructure engineers very upset.
>
> However, I don't think there's a need to invent anything new here.  
> Cookies could easily be set that indicated that Links had already  
> been consumed by a given browser. Of course, that only applies on  
> the second and subsequent requests, not the first one, so it doesn't  
> answer all your point, but it gets pretty close?
>
> Opera and FF both implement HTTP Link (see [1] for example) but  
> Chrome, Safari and IE don't. It's pretty easy therefore to configure  
> a server to include HTTP Link for those browsers based simply on the  
> UA string and put in the HTML link elements for the others? Again,  
> not a complete solution, I know, but a practical way forward?
>
> Cheers
>
> Phil.
>
> [1] http://www.fosi.org/archive/httplinktest/
>
>
>> 2009/6/19 Michael Burrows <[hidden email]>:
>>> I have a question on draft-nottingham-http-link-header-05: is  
>>> there an
>>> agreed mechanism for clients to indicate whether they want link
>>> headers, the equivalent html/xml elements, or neither?  It seems
>>> wasteful to generate redundant or unneeded data, especially while
>>> client support for the headers is not widespread.   Apologies if  
>>> this
>>> has been covered previously (I did review the April-June archive).
>>>
>>> Meanwhile, you may be interested in an experimental implementation  
>>> of
>>> link headers (&/or elements) for Ruby on Rails, generating them from
>>> metadata constructed from the application's routing config.  Please
>>> drop me a line if you'd like to play with it.  There is a Python
>>> library too but it lacks the server framework integration.
>>>
>>> I went with the hash URI approach [1] to identifying extension
>>> relation types, with the fragment pointing inside the metadata
>>> obtainable (in multiple formats) via the "describedby" links.  See  
>>> for
>>> example the last two links below:
>>>
>>>   Link: <http://example.com/users/dojo>; rel="self"; type="user",
>>>         <http://example.com/described_routes/user>;
>>> rel="describedby"; type="ResourceTemplate",
>>>         <http://example.com/described_routes/user?user_id=dojo>;
>>> rel="describedby"; type="ResourceTemplate",
>>>         <http://example.com/users>; rel="up"; type="users",
>>>         <http://example.com/users/dojo/edit>; rel="edit";
>>> rel="http://example.com/described_routes/user#edit";  
>>> type="edit_user",
>>>         <http://example.com/users/dojo/articles>;
>>> rel="http://example.com/described_routes/user#articles";
>>> type="user_articles"
>>>
>>> If I interpret the spec correctly, there is no strong guidance on  
>>> the
>>> use of the "type" attribute.  I hope that my usage here seems
>>> reasonable.
>>>
>>>   [1] http://www.w3.org/TR/cooluris/#hashuri
>>>
>>> Regards,
>>>
>>> Mike
>>> [hidden email]
>>> http://positiveincline.com
>>> http://twitter.com/asplake
>>>
>
> --
>
> Phil Archer
> http://philarcher.org/
>
> i-sieve technologies                |      W3C Mobile Web Initiative
> Beyond Impressions                  |      www.w3.org/Mobile
>

--
Mark Nottingham       [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Michael Burrows-2
2009/7/3 Mark Nottingham <[hidden email]>:
> The cookie strategy (or anything like it) isn't good for caching or scaling.

That concerns me too. I may have to accept that most clients won't be
interested in links, and let them specify explicitly (perhaps by a
query parameter) which ones they need.

>
> I think -- as in many things -- this requires a judgement call by the
> author. If you're slinging around hundreds of links on every response,
> there's a good chance that you're doing something wrong; odds are that most
> of the links will be irrelevant to most use cases. Refactoring into separate
> representations, etc. makes sense here.

I would agree.  Certainly not hundreds of links ; generally just a
handful, perhaps a few more on top level landing sites.  Anyone
wanting the template for the whole site can get that separately.

>
> In this way, it's no different to deciding what is at the other end of a
> URL; too fine-grained, and it's not useful, but too coarse-grained and
> you're giving too much information and overloading the infrastructure. Of
> course, what the infrastructure can take changes over time too.
>
> Cheers,

Regards,
Mike


>
> On 23/06/2009, at 7:11 PM, Phil Archer wrote:
>
>> Hi Michael,
>>
>>
>> Michael Burrows wrote:
>>>
>>> Re my last paragraph below, I hadn't checked RFC 4287 for a
>>> description of the "type" attribute.  Newbie error, apologies.
>>> With that out of the way, what's the thinking on the duplication of
>>> link elements and link headers?  Are there mechanisms for UAs to
>>> indicate which they prefer?  I've been through a year's worth of
>>> archive now and didn't find this addressed anywhere.
>>
>> I'm not aware of any such mechanisms but it's a point that I've heard
>> raised informally. Adding in a bunch of links in the HTTP response to every
>> request when they're not required is the kind of thing that gets server
>> infrastructure engineers very upset.
>>
>> However, I don't think there's a need to invent anything new here. Cookies
>> could easily be set that indicated that Links had already been consumed by a
>> given browser. Of course, that only applies on the second and subsequent
>> requests, not the first one, so it doesn't answer all your point, but it
>> gets pretty close?
>>
>> Opera and FF both implement HTTP Link (see [1] for example) but Chrome,
>> Safari and IE don't. It's pretty easy therefore to configure a server to
>> include HTTP Link for those browsers based simply on the UA string and put
>> in the HTML link elements for the others? Again, not a complete solution, I
>> know, but a practical way forward?
>>
>> Cheers
>>
>> Phil.
>>
>> [1] http://www.fosi.org/archive/httplinktest/
>>
>>
>>> 2009/6/19 Michael Burrows <[hidden email]>:
>>>>
>>>> I have a question on draft-nottingham-http-link-header-05: is there an
>>>> agreed mechanism for clients to indicate whether they want link
>>>> headers, the equivalent html/xml elements, or neither?  It seems
>>>> wasteful to generate redundant or unneeded data, especially while
>>>> client support for the headers is not widespread.   Apologies if this
>>>> has been covered previously (I did review the April-June archive).
>>>>
>>>> Meanwhile, you may be interested in an experimental implementation of
>>>> link headers (&/or elements) for Ruby on Rails, generating them from
>>>> metadata constructed from the application's routing config.  Please
>>>> drop me a line if you'd like to play with it.  There is a Python
>>>> library too but it lacks the server framework integration.
>>>>
>>>> I went with the hash URI approach [1] to identifying extension
>>>> relation types, with the fragment pointing inside the metadata
>>>> obtainable (in multiple formats) via the "describedby" links.  See for
>>>> example the last two links below:
>>>>
>>>>  Link: <http://example.com/users/dojo>; rel="self"; type="user",
>>>>        <http://example.com/described_routes/user>;
>>>> rel="describedby"; type="ResourceTemplate",
>>>>        <http://example.com/described_routes/user?user_id=dojo>;
>>>> rel="describedby"; type="ResourceTemplate",
>>>>        <http://example.com/users>; rel="up"; type="users",
>>>>        <http://example.com/users/dojo/edit>; rel="edit";
>>>> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>>>>        <http://example.com/users/dojo/articles>;
>>>> rel="http://example.com/described_routes/user#articles";
>>>> type="user_articles"
>>>>
>>>> If I interpret the spec correctly, there is no strong guidance on the
>>>> use of the "type" attribute.  I hope that my usage here seems
>>>> reasonable.
>>>>
>>>>  [1] http://www.w3.org/TR/cooluris/#hashuri
>>>>
>>>> Regards,
>>>>
>>>> Mike
>>>> [hidden email]
>>>> http://positiveincline.com
>>>> http://twitter.com/asplake
>>>>
>>
>> --
>>
>> Phil Archer
>> http://philarcher.org/
>>
>> i-sieve technologies                |      W3C Mobile Web Initiative
>> Beyond Impressions                  |      www.w3.org/Mobile
>>
>
> --
> Mark Nottingham       [hidden email]
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

Phil Archer-3
Incidentally, there's now an HTTP link from http://www.w3.org/Mobile/ 
which points to the POWDER file that describes the page as being
mobileOK. See the headers at http://tinyurl.com/npybzg

Phil.

Michael Burrows wrote:

> 2009/7/3 Mark Nottingham <[hidden email]>:
>> The cookie strategy (or anything like it) isn't good for caching or scaling.
>
> That concerns me too. I may have to accept that most clients won't be
> interested in links, and let them specify explicitly (perhaps by a
> query parameter) which ones they need.
>
>> I think -- as in many things -- this requires a judgement call by the
>> author. If you're slinging around hundreds of links on every response,
>> there's a good chance that you're doing something wrong; odds are that most
>> of the links will be irrelevant to most use cases. Refactoring into separate
>> representations, etc. makes sense here.
>
> I would agree.  Certainly not hundreds of links ; generally just a
> handful, perhaps a few more on top level landing sites.  Anyone
> wanting the template for the whole site can get that separately.
>
>> In this way, it's no different to deciding what is at the other end of a
>> URL; too fine-grained, and it's not useful, but too coarse-grained and
>> you're giving too much information and overloading the infrastructure. Of
>> course, what the infrastructure can take changes over time too.
>>
>> Cheers,
>
> Regards,
> Mike
>
>
>> On 23/06/2009, at 7:11 PM, Phil Archer wrote:
>>
>>> Hi Michael,
>>>
>>>
>>> Michael Burrows wrote:
>>>> Re my last paragraph below, I hadn't checked RFC 4287 for a
>>>> description of the "type" attribute.  Newbie error, apologies.
>>>> With that out of the way, what's the thinking on the duplication of
>>>> link elements and link headers?  Are there mechanisms for UAs to
>>>> indicate which they prefer?  I've been through a year's worth of
>>>> archive now and didn't find this addressed anywhere.
>>> I'm not aware of any such mechanisms but it's a point that I've heard
>>> raised informally. Adding in a bunch of links in the HTTP response to every
>>> request when they're not required is the kind of thing that gets server
>>> infrastructure engineers very upset.
>>>
>>> However, I don't think there's a need to invent anything new here. Cookies
>>> could easily be set that indicated that Links had already been consumed by a
>>> given browser. Of course, that only applies on the second and subsequent
>>> requests, not the first one, so it doesn't answer all your point, but it
>>> gets pretty close?
>>>
>>> Opera and FF both implement HTTP Link (see [1] for example) but Chrome,
>>> Safari and IE don't. It's pretty easy therefore to configure a server to
>>> include HTTP Link for those browsers based simply on the UA string and put
>>> in the HTML link elements for the others? Again, not a complete solution, I
>>> know, but a practical way forward?
>>>
>>> Cheers
>>>
>>> Phil.
>>>
>>> [1] http://www.fosi.org/archive/httplinktest/
>>>
>>>
>>>> 2009/6/19 Michael Burrows <[hidden email]>:
>>>>> I have a question on draft-nottingham-http-link-header-05: is there an
>>>>> agreed mechanism for clients to indicate whether they want link
>>>>> headers, the equivalent html/xml elements, or neither?  It seems
>>>>> wasteful to generate redundant or unneeded data, especially while
>>>>> client support for the headers is not widespread.   Apologies if this
>>>>> has been covered previously (I did review the April-June archive).
>>>>>
>>>>> Meanwhile, you may be interested in an experimental implementation of
>>>>> link headers (&/or elements) for Ruby on Rails, generating them from
>>>>> metadata constructed from the application's routing config.  Please
>>>>> drop me a line if you'd like to play with it.  There is a Python
>>>>> library too but it lacks the server framework integration.
>>>>>
>>>>> I went with the hash URI approach [1] to identifying extension
>>>>> relation types, with the fragment pointing inside the metadata
>>>>> obtainable (in multiple formats) via the "describedby" links.  See for
>>>>> example the last two links below:
>>>>>
>>>>>  Link: <http://example.com/users/dojo>; rel="self"; type="user",
>>>>>        <http://example.com/described_routes/user>;
>>>>> rel="describedby"; type="ResourceTemplate",
>>>>>        <http://example.com/described_routes/user?user_id=dojo>;
>>>>> rel="describedby"; type="ResourceTemplate",
>>>>>        <http://example.com/users>; rel="up"; type="users",
>>>>>        <http://example.com/users/dojo/edit>; rel="edit";
>>>>> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>>>>>        <http://example.com/users/dojo/articles>;
>>>>> rel="http://example.com/described_routes/user#articles";
>>>>> type="user_articles"
>>>>>
>>>>> If I interpret the spec correctly, there is no strong guidance on the
>>>>> use of the "type" attribute.  I hope that my usage here seems
>>>>> reasonable.
>>>>>
>>>>>  [1] http://www.w3.org/TR/cooluris/#hashuri
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mike
>>>>> [hidden email]
>>>>> http://positiveincline.com
>>>>> http://twitter.com/asplake
>>>>>
>>> --
>>>
>>> Phil Archer
>>> http://philarcher.org/
>>>
>>> i-sieve technologies                |      W3C Mobile Web Initiative
>>> Beyond Impressions                  |      www.w3.org/Mobile
>>>
>> --
>> Mark Nottingham       [hidden email]
>>
>>
>>
>>
>

--

Phil Archer
http://philarcher.org/

i-sieve technologies                   |      W3C Mobile Web Initiative
Sentiment Analysis Beyond Impressions  |      www.w3.org/Mobile