- 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 ofMessage 1 of 13 , Mar 15 11:01 PMView SourceI 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.
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.
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.
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.
From: Elias Sinderson [mailto:elias@...]
Sent: Wednesday, 16 March 2005 12:33 PM
To: Donald Strong
Cc: John Elliot; firstname.lastname@example.org
Subject: Re: [rest-discuss] URIs and 'pagination'
Donald Strong wrote:
>[...] Now if you have more than one thing and many of them are two large tobe displayed in their entirety, perhaps because they are potentially large
lists, then you might provide a generic way of pagenating them using
>There is a generic mechanism specified for HTTP/1.1 in the form of
various request / response headers. Specifically, I refer to the
Accept-Ranges, Content-Range, If-Range and Range headers. I responded as
much to John off list but hadn't the time to reference the spec for a
definitive answer. There are some difficulties in that clients and
servers aren't required to support these features, however all of the
issues I've considered can be addressed with redirects, proxies, etc.
>[...] once you have decided on content how do you lock it into the URI?Segment parameters perhaps? Others will have
>opinions on this.My preference is to *not* encode content type in the URI at all. Again,
HTTP provides several Accept headers for this purpose and, also again,
there are some difficulties associated with this approach due to the
fractured implementation landscape that one can work around if there is
a desire to be 'pure' about it.
>But then there is the slicing up into pages which does not fit into contentnegotiation. If you use the analogy of a query is like asking a question of
a resource then the question is "can I see the first 10 of your items
> /my-app/my-thing?range=1-10I mentioned the various Range headers above, and I should not that
HTTP/1.1 only specifies *byte* ranges, although the mechanism is
extensible and pagination seem like a reasonable addition - at least for
>I notice that the way it is done on the rest-discuss web site is [...] Thisseems a reasonably neat and understandable way of doing it. It defines
another set of resources, each of which is a list of messages. This
effectively moves one parameter from the query side to the path side of the
>There is no 'one way suits all' in this, but I hope the suggestions aboveare a help.
>In the context of pagination, this approach requires storing each page
as a separate resource, analogous to the way email messages are
represented in the example. This may be a reasonable approach, depending
on the application, but potentially leads to other content and version
management issues. ... I agree that there is no one solution as Donald
mentions, but will vary by the application and, to a lesser extent, the
feature sets supported by the client(s) and server(s).
- ... 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 specMessage 2 of 13 , Mar 16 1:14 AMView SourceDonald 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. REST is defined by four interface constraints:Message 3 of 13 , Mar 16 6:50 AMView SourceOn 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