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

WordPress Trac noreply at wordpress.org
Thu Sep 22 15:38:18 UTC 2016


#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       |   Keywords:
  Focuses:  performance  |
-------------------------+-----------------------------
 A frequent request in the API content routes plugin (see discussion in
 [https://github.com/WP-API/WP-API/issues/446 #446], [https://github.com
 /WP-API/WP-API/issues/445 #445]) is to provide a mechanism to include or
 exclude specific fields from the response JSON, to simplify the response
 object and to limit the size of the object that must be transferred down
 to the requesting client.

 This was de-scoped a few years back in [https://github.com/WP-API/WP-
 API/issues/572 #572] as plugin territory, because it was not felt to meet
 the 80/20 balance necessary to deal with it in a first-party way, but it's
 been one of the most consistently discussed issues since. Since field
 inclusion or exclusion relates to the core infrastructure of the API and
 not to the specific routes provided in the REST API plugin, the right
 place for this discussion to continue is here on Trac.

 The ask, from API consumers: provide a query parameter argument that can
 be used to include or exclude fields from the response JSON. Variations of
 `?fields[]=title&fields[]=excerpt&fields[]=id` have been discussed (and
 implemented in [https://wordpress.org/plugins/wp-rest-api-filter-fields/
 at least one plugin]), while [https://github.com/elyobo/wp-rest-jmespath
 another plugin] has been implemented that uses [http://jmespath.org/
 JMESPath] to specify the fields to include.

 Advantages:

 - Smaller JSON transferred over the wire;
 [https://www.ericsson.com/res/docs/2016/mobility-report/ericsson-mobility-
 report-feb-2016-interim.pdf bandwidth is extremely precious (Ericsson
 Mobility Report, Feb 2016)] and transferring as little data as is
 necessary for a given interface is a responsibility we should take on as
 application developers. If you're rendering out a generic archive list you
 likely do not need all of the post content, e.g., and you'll be saving
 people time and money by not including that in the download.
 - Minor developer convenience improvement to be able to request and work
 with only what you want

 Disadvantages:

 - There is no impact to the underlying queries performed, so while
 limiting fields saves on bandwidth performance it does not impact server
 performance
 - Could prohibit effective server caching of responses in some cases,
 negatively impacting time to response

 I move to continue the discussion around providing this functionality as a
 first-party capability of the API infrastructure, as I believe we should
 be doing whatever we can to provide means of reducing the bandwidth
 necessary to consume WordPress content through the API.

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


More information about the wp-trac mailing list