The twitter API originally used pages, but they realized it was a mistake: 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... .

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.