If you had a article and you included comments, all of the comments would be returned in the response.
Now lets say that this article has 100,000 comments associated to it. If we returned all 100,000 comments in one request, the server might timeout or the amount data may be too large.
In this case, is there a way to paginate the number of comments in the relationships/included array?.. should we not allow for includes? … is there something that I have not thought of?
Did you ever get an answer for this? What did you decide to do?
The only thing the relevant section of specs (http://jsonapi.org/format/#fetching-pagination) says is this:
“Pagination links MUST appear in the links object that corresponds to a collection. To paginate the primary data, supply pagination links in the top-level links object. To paginate an included collection returned in a compound document, supply pagination links in the corresponding links object.”
My problem is understanding what exactly is the links object that corresponds to items in the included section - since that section is an array, I don’t see where that links object would even go.
TLDR;
We did not implement includes.
After theory-crafting out scaling issues, it became apparent we would need to paginate includes if we returned them… BUT we would also want to have a mechanism for allowing to specify what “page” we are paginating each includes on and return them properly. This was a pain in the … well you know. It also came to our attention that if we did paginate the includes, some partners may assume the includes we would returning are all of them, not just a subset.
Because the spec does no specify how to do this completely, we decided not to implement includes. (includes are not required for spec as far as I can tell). This does mean partners must make more requests. But the up side: we can limit the number of queries per request to a manageable number and keep response times sub 100ms.