Tuesday, April 22, 2008

HTTP Ranges for Pagination?

Would it be a gross perversion to use HTTP ranges for pagination?:



Client asks the server what range types it accepts for people:



HEAD /people HTTP/1.1



Server responds:



Status: 200
Accept-Ranges: pages; records



Client requests the first page of people:



GET /people HTTP/1.1
Range: pages=1-1



Server Responds:



Status: 206
Content-Range: pages 1-1/13



6 comments:

Will Green said...

A gross perversion? Probably not. The HTTP/1.1 spec is pretty open when it comes to the Accept-Ranges and Range headers:
*The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units.*
The problem is in getting the clients to send Range headers with their requests.

Dave Mauldin said...

When discussing "rich clients", you're talking about returning records x pages of y records at a time. Do you just leave y up to the application?
It seems that we'd be better served by only using this header to specify which records to return, not pages.

Simon Harris said...

Not sure what I'm talking about hehehe. I was more exploring the possibilities :) I agree that record is a more appropriate level of granularity but I wanted something else for comparison.

Michael Neale said...

I can hear the sound of bob marley in the background, and see thick smoke. This would be a RESTafarians dream ;)

Simon Harris said...

The more I think about it the more I like it. The only thing you don't get is bookmarkable pagination but as I stated in my earlier comment, I'm really not trying to support full-page refresh browsing. I'm more interested in supporting rich-clients using RESTful APIs over HTTP.

Simon Harris said...

Indeed. When I read the spec it seemed to imply I could use it to do exactly what I wanted and when the client is a Javascript application sending XML HTTP Requests that's pretty easy to achieve.

Post a Comment