Arguments to sort and include only apply to the primary resource being requested. This means that there's no limit to the amount of relationships (and worse, included resources) one can get back.

Perhaps we should allow specifying what they are sorting, by specifying the type:

GET /articles?sort=-id
vs
GET /articles?sort[articles]=-id

This would allow requests like this:
GET /articles?sort[authors]=-id # Sort the authors relationships by id
GET /articles?include=authors,comments&sort[include]=-people.id # Sort the included array by the people's id.

I think we could modify sort that way fairly easily. page could follow a similar pattern:

GET /articles?page[number]=5
vs
GET /articles?page[articles][number]=5

The problem here is when trying to page relationships or includes; there's no way to do this without breaking the spec, because of this:

http://jsonapi.org/format/#document-top-level
Primary data MUST be either:

a single resource object, a single resource identifier object, or null, for requests that target single resources
an array of resource objects, an array of resource identifier objects, or an empty array ([]), for requests that target resource collections

There is no place for us to place a links member with the pagination links!

Same situation with include -- spec says to return a collection, so we can't put the pagination in there.

Any ideas? Should we file this one under potential future extensions?