[wp-trac] [WordPress Trac] #38131: REST API: Provide interface to include or exclude specific fields from response JSON

[WordPress Trac]

#38131: REST API: Provide interface to include or exclude specific fields from
response JSON
-------------------------+------------------------------
 Reporter:  kadamwhite   |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  performance
-------------------------+------------------------------

Comment (by kadamwhite):

 After [https://github.com/WP-API/WP-API/pull/2773 re-opening discussion of
 adding this parameter] on the REST API plugin repository, I've uploaded
 initial patch based on a PoC @rmccue created, adapted for use within core
 instead of as a plugin. The implementation here follows the comma-
 separated `fields=fieldname1,fieldname2` paradigm used with the .com API,
 among others, with the parameter key switched to `_fields` to match the
 other core API properties. (Although "context" is still un-underscored).

 I have some open questions for discussion:

 - `context` is always specified in the accepted `args` for get collections
 in the API index (on /wp-json/); `_embed` and other underscore-prefixed
 properties are not. Should this property be specified in the schema
 anywhere?
 - This currently will remove `_links` on collection responses, and
 maintain them on single-item responses: the inconsistency is bad on its
 own, but it raises the question of whether `_links` should be excludable
 via this mechanism. I lean towards yes because since _fields as
 implemented here is opt-in only it is up to the consumer of the API to
 specify what they want, and if they do not want _links excluding it saves
 a lot of size (particularly in collection responses).
 - This code may be in the wrong place within core's codebase
 - Should this be supported for all types of request, or just GET? I lean
 towards supporting broadly
 - I've never written unit tests for core before, these may be over verbose
 or malformed in some way.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38131#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform