WordPress.org

Make WordPress Core

Opened 6 weeks ago

Last modified 6 weeks ago

#42094 new enhancement

REST API: extend _fields parameter to selectively include nested fields in response JSON

Reported by: kadamwhite Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.9
Component: REST API Keywords:
Focuses: Cc:

Description

This enhancement has been broken out from #38131, which introduced the _fields query parameter to whitelist select fields for inclusion in the API response object.

In the comments of that ticket @TimothyBlynJacobs uploaded a patch with support for nested fields, such as returning title.raw while omitting title.rendered:

[patch 31131.3.diff allows] specifying title.raw for just the raw title or title to retrieve both the raw and rendered title. This could also be used by controllers to only calculate the fields as necessary. I'm not sure whether this should be used to limit the fields queried ( I think that can be done in WP_User_Query but I'm not sure about the others ). I imagine some of the performance benefits here, besides response size, would be not filtering the_content if it wasn't a requested field, for instance.

There's been discussion of how feasible it is to use these parameters to hint that certain types of data processing are unnecessary, but on its own the base use-case of "give me the raw API response without its rendered counterpart" in edit mode could significantly speed up initial load of editor interfaces on slow connections.

This nesting feature has also been proven out in the plugin repository in the rest-api-filter-fields and wp-rest-mespath, the former through the same basefield.nestedfield syntax and the latter through JMESPath.

Attachments (1)

42094.1.diff (1.1 KB) - added by kadamwhite 6 weeks ago.
Basic unit test exploring the proposed dot-nested ?_fields syntax

Download all attachments as: .zip

Change History (2)

@kadamwhite
6 weeks ago

Basic unit test exploring the proposed dot-nested ?_fields syntax

#1 @kadamwhite
6 weeks ago

Added a patch with a basic unit test exloring the dot-nested syntax proposed above. I propose that the dot-separated solution is preferable to JMESPath for core usage, as it will be a straightforward enhancement over the initial syntax from #38131.

Note: See TracTickets for help on using tickets.