mca blog

earlier this year, there was some discussion on the SDS forum about adding paging support to SDS responses. however, when it came up, SDS didn't have it's Take(n) query function yet and the details of paging were pretty sketchy. now that Take(n) is here, it's time (IMO) to revive the talk of paging metadata for SDS queries.

below is the suggestion i posted as part of my SDS Feature Wish List page:

Currently SDS returns a maximum of 500 entities per query regardless of the number of entities that match the query criteria. Going forward it is important to provide support for paging control. Ideally this should be done as message metadata, not as part of the query itself. One possible exception would be to use the Take(n) query function currently supported by SDS as part of the paging control metadata. A good example of a pattern already 'vetted' by the community is the Feed Paging and Archiving standard developed for the Atom MIME-type. Since SDS seems committed to supporting Atom at some point in the future, using the above-mentioned RFC standard seems a good target.

For MIME-types other than Atom, it is suggested that a set of custom HTTP Headers be employed to cover the same values. Suggested names are: x-paging-first, x-paging-previous, x-paging-next, x-paging-last. In line with RFC5005 (see above), the values should be links, not scalar values. This allows the greatest flexibility for future changes to the way paging is used and/or computed (i.e. x-paging-next: http://example.com/container/entity-25)

Another possible solution would be to consider the HTTP Header Linking draft from Mark Nottingham (i.e. link:<http://example.com/container/>; rel="first"). While this draft is currently dormant, it has potential for wider acceptance over adopting custom HTTP headers.