6 ms·
The twitter API originally used pages, but they realized it was a mistake: https://dev.twitter.com/docs/working-with-timelines https://dev.twitter.com/docs/work
by jeffamcgee 13y ago
The twitter API originally used pages, but they realized it was a mistake: https://dev.twitter.com/docs/working-with-timelines https://dev.twitter.com/docs/working-with-timelines . The way the facebook API does it is a lot more sane: http://developers.facebook.com/docs/reference/api/pagination/ http://developers.facebook.com/docs/reference/api/pagination... .
I think that you should specify the format for cursor based paging of resource collections. One way to do it would be to require a url to get more results:
{
"posts": [...]
"meta": {
"next":"/posts/search?q=baseball&after=1234"
}
}
Another option would be for it to be a key/value pair that must be added to the url:
{
"posts": [...]
"meta": {
"next":"after=1234"
}
}
Either way, rest clients should treat it as a meaningless string.
- wycats 13y agoAgreed. If I standardize pagination, I'll be using a "since" token, not pages (this is actually something Ember Data already supports, but weakly).
- steveklabnik 13y agoCurrently, we don't say anything about searching. That's really an application-level concern, not something that needs to be in this spec. (So you'd define your own rels and use them, doesn't affect this level of abstraction.)