Re: [rest-discuss] URIs and 'pagination'
- Donald Strong wrote:
>I don't think Range headers are up to the job, Elias. From my reading of the spec they work at the transfer layer (HTTP) for retrieving parts of representations that were only partly downloaded.Yes, byte ranges will work as you describe, however there seems to be no
reason that other range units could not be defined in the future and the
spec doesn't forbid this. (Here we are walking along the thin line which
forms the very edge of HTTP-land.)
>I also think it would be inappropriate to extend the Range headers to include page information because then the URI would mean different things depending upon the Range headers.I don't follow you - Consider the above satement in light of other
accept headers such as content or language encoding. As always, the URI
will specify the resource, regardless of the headers.
>Sometimes that is appropriate, for example when the representation differs depending upon authorization credentials, but in this case I think it would be inappropriate. For one thing it would be impossible to bookmark the page.Okay, so we agree that this approach in general will be more or less
appropriate depending on the specific application - I stated as much in
my previous email. Yet there is nothing special about 'bookmarkability'
which factors into this, as bookmarks are neither part of REST nor HTTP.
... It's not that I don't appreciate the usefullness of bookmarks, but
it is important to acknowledge that the web browser doesn't define REST
or HTTP and is, in fact, a rather impoverished client as far as both are
concerned. This has been discussed several times before on the list.
Regarding bookmarkability, there is no reason that some client, an
HTTP-based eBook reader, for example, couldn't bookmark both the URI and
location within the resource as either a byte position or page number.
>I have often wondered what Range headers could be used for at the application level. The only practical use I can think of is to get the tail of a resource that is constantly being extended. Kind of a 'tail -f' over the internet.That is a fine example, thanks. Another good set of examples / use cases
involve clients with limited device profiles accessing large media files
- music, video or large PDFs, perhaps, or other content types may be
defined in the future. ... Digitized microfish may also be a reasonable
use case, depending on how the resources are broken up, but I can
imagine requesting a page range from a newspaper printed a hundred years
ago and getting a multipart response back with an image in each part. In
some cases there may be a direct correlation between byte ranges and
page ranges depending on the application and / or media type.
That being said, there is a pragmatic aspect to the original question
which should not be ignored but, after all, this is rest-discuss as
opposed to, say, web-applications-circa-2005-discuss. Hopefully
exploring the various possibilities mentioned in this thread hasn't been
too much of a turn off for those list members burdened with actually
delivering functional web-based applications. :-D
- On Tue, 15 Mar 2005 22:23:44 -0800, S. Mike Dierken
>+1 Hypermedia is the engine of application state.
> > Now if you have more than one thing and many of them are two
> > large to be displayed in their entirety, perhaps because they
> > are potentially large lists, then you might provide a generic
> > way of pagenating them using standard parameters.
> It's probably better to use a reference to the other pagination blocs via
> links within the content of a representation - hypertext. Rather than
> standardizing on the format of a URL,you only need to standardize on where
> the 'next' and 'prev' link can be found. You can also get more sophisticated
> than just 'next' and 'prev'.
"REST is defined by four interface constraints: identification of
resources; manipulation of resources through representations;
self-descriptive messages; and, hypermedia as the engine of
The use of 'next' links to navigate large collections of resources is
the solution we just came to concensus on for the Atom Publishing
Joe Gregorio http://bitworking.org