Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] URIs and 'pagination'

Expand Messages
  • Elias Sinderson
    ... 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
    Message 1 of 13 , Mar 16, 2005
    • 0 Attachment
      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

    • Joe Gregorio
      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 2 of 13 , Mar 16, 2005
      • 0 Attachment
        On Tue, 15 Mar 2005 22:23:44 -0800, S. Mike Dierken
        <mdierken@...> wrote:
        > >
        > > 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'.

        +1 Hypermedia is the engine of application state.

        "REST is defined by four interface constraints: identification of
        resources; manipulation of resources through representations;
        self-descriptive messages; and, hypermedia as the engine of
        application state."[1]

        The use of 'next' links to navigate large collections of resources is
        the solution we just came to concensus on for the Atom Publishing
        Protocol [2].


        [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5
        [2] http://www.intertwingly.net/wiki/pie/PaceSliceAndDice3

        Joe Gregorio http://bitworking.org
      Your message has been successfully submitted and would be delivered to recipients shortly.