- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Mon, 12 Nov 2012 13:43:19 -0500
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- CC: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, James M Snell <jasnell@gmail.com>
hello james. On 2012-11-12 9:36 , "James M Snell" <jasnell@gmail.com> wrote: >Just as an fyi to add to the discussion.. one of the Atom extensions I >experimented with but never got around to writing up is a <link-template> >element analogous to atom:link that uses a URI Template instead.. e.g. > <link-template rel="next" href="http://example.org/foo{?page}" /> >In my various experiments this worked fine but it was never put into >practice because using opaque links proved to be all that was required in >our specific implementation(s). as long as links can be static (i.e., don't need any runtime parameters such as page size or page number), i agree that using static links and fully opaque URIs is the better way to go, because less machinery is required on the client. once you get into parametrized services, though, there's a natural limit to this, and your design options are pretty much to use URI templates, or push the parameters into the request body (which then gets you into the awkward territory of designing a protocol that uses GET with a body http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html ). and an off-list request: james, any interest in spec'ing rfc5005++ with URI templates, adding stuff such as page size and random page access, and defining an extension model for services to also expose their own additional parameters? cheers, dret.
Received on Monday, 12 November 2012 18:44:19 UTC