How To Delete Some Info From API #2771
Comments
See here to learn how to modify the responses with a plugin script. http://v2.wp-api.org/extending/modifying/ Or you could create your own namespaced endpoints and deliver what you need. |
Well,I don't want to make a ext . i just want to hide the content for save bandwidth |
well, i can make new namespace , but i also want it can add to do list |
I found this useful : http://boris.kuzmanov.ninja/wp-rest-api-modifying-json-response/ But I would recommend a custom endpoint. As they mention on the Modifying Responses page, it can be unwise to remove fields from the standard wp/v2 responses, as other clients might expect the fields to be present. |
How about something like this? Using a custom
then hit |
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/
@kosso @bestony I'm closing this as superseded by https://core.trac.wordpress.org/ticket/38131 which proposes a |
Thanks for raising this, by the way; it's been weighing on my mind that we don't have an interface for it and this was a good push to try to do something about it :) |
👍 |
1 similar comment
👍 |
I Want to Only show title,author,id exclude content to save bandwidth for some bad network
The text was updated successfully, but these errors were encountered: