This repository has been archived by the owner on Sep 24, 2018. It is now read-only.
jmespath support to limit responses #2350
Comments
See #572. We're unlikely to add this to the main plugin right now, as this is plugin territory for now. You can use either the |
Thanks for the pointers. |
Proof of concept at https://github.com/elyobo/wp-rest-jmespath |
If you have any feedback let me know, otherwise please add it to the list of compatible plugins. |
Awesome! If you pop us a pull request on the docs repo with the description you'd like, happy to add that for you :) |
Thanks @rmccue PR added at WP-API/docs-v2#126 now that the plugin is published on wp.org. |
kadamwhite
added a commit
that referenced
this issue
Oct 7, 2016
This PR builds upon discussion in #2771, #572, #2350, #2509, #1530, #1371, #446, #827, and the trac ticket [38131][trac], proposing an solution implemented within this plugin's wp-rest-controller class. The patch implements a `?fields=` filter parameter that takes a comma- separated list of field names, e.g. "id" and "title". It mirrors the fields parameter implemented within the [WordPress.com API][wpcom]: Parameter | Type | Description --- | --- | --- fields | (string) | Optional. Returns specified fields only. Comma-separated list. Example: fields=ID,title This interface was previously implemented in [this plugin][origplugin], and could still be implemented trivially as a plugin; however, referencing the [2016 Ericsson Mobility Report][mobility-report] and the democratic focus of WordPress, transferring as little data as is necessary for a given interface is a responsibility I submit that we should take on as application developers, and that _should_ therefore be a first-party capability of the API, as it is for .com's. Introducing this field has no risk of breaking the contract between the API and clients you do not control, as the `fields` list would only alter the response when provided so each client can tailor its own responses to the subset of data relevant to that interface. Open questions: - Is there a less repetitive way this could be implemented across controllers, or is this duplication within each controller necessary? - How would I register `fields` as a globally-applicable parameter for exposure in the schema, whitelisting, etc? - How sould/How should we restrict this to GET requests only? - What degree of per-controller testing is needed? [mobility-report]: https://www.ericsson.com/res/docs/2016/mobility-report/ericsson-mobility-report-feb-2016-interim.pdf [trac]: https://core.trac.wordpress.org/ticket/38131 [wpcom]: https://developer.wordpress.com/docs/api/1.1/get/sites/%24site/posts/ [origplugin]: https://wordpress.org/plugins/wp-rest-api-filter-fields/
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Feature request -
The documentation sensibly suggests that users avoid modifying standard responses to avoid problems when using other clients that expect those fields to be present. The AWS CLI supports this with the --query argument which makes use of JMESPath (PHP library) to allow clients to better filter the data that they want without modifying the underlying data format (the standard format would remain for other clients).
Implementing support for this in the REST plugin would reduce the need for users to remove fields from the data. If there is an appropriate filter that fires just before the rest API sends the response then this could easily be packaged into a plugin as well.
The text was updated successfully, but these errors were encountered: