Problem/Motivation
Provide an option to get all results for a collection rather than being limited to paged results.
Proposed resolution
The getCollection method will accept a boolean 'all' option. If this is provided, we'll iterate through all pages of JSON:API results to return all data rather than returning only one page of results.
getResource and getCollection currently share the GetOptions interface. We might need to extend this in a new GetCollectionOptions interface - I don't think an all option makes sense for getting a single resource.
Remaining tasks
* Implement 'all' option for getResource.
* Add test coverage.
* Add inline documentation.
API changes
Options for getCollection will now accept a boolean 'all' option.
Issue fork api_client-3398405
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
pratik_kamble@brianperry I did not fully understand what is expected output here? Do we want to disable pagination? Because as far as I know we can't get disable pagination for JSONAPI client.
Comment #3
brianperry@pratik_kamble - you are correct that there is no way to disable paging of the JSON:API endpoint. This would essentially be providing a helper on our end to automatically get all paged results.
In DrupalState we had an 'all' option
This passage of code is how we approached it in that library: https://git.drupalcode.org/project/drupal_state/-/blob/1.0.x/src/DrupalS...
Comment #4
brianperryAdded a little more detail to the issue description.
Comment #5
pratik_kambleComment #6
pratik_kamble@brianperry What should be response if the both `rawreponse` and `all` flag is true.
Comment #7
brianperry@pratik_kamble that's a good question. If forced to choose with both flags I think 'all' would have to override 'rawResponse' - either just ignoring it, or throwing an error when both exist.
But as you seem to imply, that feels like it is in conflict with our interface. And the JSON:API spec for that matter.
I'm inclined to say that we postpone this for now in favor of leading people to use JSON:API as intended by the spec. If we hear demand for this feature we can reconsider.
Comment #8
brianperry