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

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

Expand Messages
  • Donald Strong
    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
    Message 1 of 13 , Mar 15 11:01 PM
    • 0 Attachment
      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.

      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.

      Regards
      Donald.


      -----Original Message-----
      From: Elias Sinderson [mailto:elias@...]
      Sent: Wednesday, 16 March 2005 12:33 PM
      To: Donald Strong
      Cc: John Elliot; rest-discuss@yahoogroups.com
      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 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.
      >
      >
      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-app/my-thing;content=pdf
      >
      >
      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 content
      negotiation. 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
      please".
      > /my-app/my-thing?range=1-10
      >
      >
      I 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
      *some* applications.

      >I notice that the way it is done on the rest-discuss web site is [...] This
      seems 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
      URI.
      >There is no 'one way suits all' in this, but I hope the suggestions above
      are 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).


      Cheers,
      Elias
    • 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 2 of 13 , Mar 16 1:14 AM
      • 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


        Best,
        Elias
      • 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 3 of 13 , Mar 16 6:50 AM
        • 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].

          -joe

          [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.