Not quite. When following the next link the response’s primary data will be only the next set of resource identifier objects, like this:
{
"data": [
/* second x resource identifier objects */
],
// optionally, you can add links too
"links": {
"prev": "http://url.com/v1/test/1/relationships/testpoints?pagenumber=1&pagesize=x",
"next": "http://url.com/v1/test/1/relationships/testpoints?pagenumber=3&pagesize=x",
"related": "http://url.com/v1/test/1/testpoints"
}
}
The idea here is that the original testpoints relationship is a collection of resource identifier objects, so its pagination links should all return portions of that collection as their primary data.
Yes, but those links should go under each relationship in the original response for the "test1" resource. So, the full response for the tests collection would look like this:
// GET /v1/tests?include=testpoints
{
"data": [{
"type": "test",
"id": "test1",
"links": {
"self": "http://url.com/v1/tests/1"
}
"attributes": { /* data for test1 */ },
"relationships": {
"testpoints": {
"data": [ /* first x linkage items here */ ],
"links": {
"next": "http://url.com/v1/test/1/relationships/testpoints?pagenumber=2&pagesize=x",
"related": "http://url.com/v1/test/1/testpoints"
}
},
"uut": {
// exactly the same structure (with limited data + next)
// as the testpoints relationship
}
}
},
/* 9 other test resources here */
],
"included": [
// full resources for all the resource identifier objects
// given in the data above for the requested relationships.
// i.e. `?include=testpoints` will lead to 10*x resources being
// stored here (10 for each test0; `?include=testpoints,uut`
// would have 2*10*x.
],
"links": {
"next": "http://url.com/v1/tests?include=testpoint&pagenumber=2&pagesize=10",
"prev": null,
"last": "http://url.com/v1/tests?include=testpoint&pagenumber=37&pagesize=10",
"self": "http://url.com/v1/tests?include=testpoint"
},
"meta": { /* custom pagination info for the tests collection */ }
}
Yup, on collections too!
I’m not sure I understand this. In JSON API terms, “fields” just means a resource’s attributes and relationships. Attributes can’t be paginated (since their values are just single blobs of data from the spec’s POV, not lists) and relationships are paginated per above.