Add field include/exclude parameters to change which fields are returned #572
Comments
|
Can you explain a bit the idea/rationale for implementing that as part of a plugin? Would that mean defining a separate API endpoint or extending the current one with more 'filtering' capabilities? |
|
@dsebastien I think basically we didn't think this fit the 80/20 split. The thought was a simple add-on plugin could make the necessary hooks in to modify the existing endpoints to remove any fields that were not requested for any request. |
|
I've added a simple plugin which allows very flexible field selection (among other things) at https://github.com/elyobo/wp-rest-jmespath; it's very simple, just listening in before the response is sent and using JMESPath to do all the heavy lifting. JMESPath allows doing lot more than just field selection and seems like a pretty good fit for this problem to me. |
|
See also https://wordpress.org/plugins/wp-rest-api-filter-fields/ (from comment in #446); may be stale, hasn't been updated in a year. |
|
I'm moving this discussion to Trac, since this is a concern that would need to be tackled on the core infrastructure side. I believe this is important functionality to include, and agree that it should be tried out in plugins before we consider merging it into core. Trac ticket: https://core.trac.wordpress.org/ticket/38131#ticket |
|
See also the simple jmespath plugin I added for this; a steeper learning curve (you need a little JMESPath knowledge - http://jmespath.org), but more flexible in what it allows and will work with any type of |
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/
Commonly requested feature.
We're going to do this in a plugin, as suggested by @danielbachhuber.
The text was updated successfully, but these errors were encountered: