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

WordPress Trac noreply at wordpress.org
Tue Nov 29 01:33:23 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:  Future Release
Component:  REST API     |     Version:  4.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  performance
-------------------------+-----------------------------
Changes (by jnylen0):

 * version:   => 4.4


Comment:

 Replying to [comment:4 rmccue]:

 > In particular, this has the potential to ruin both PHP and server
 caches.

 I'm not sure this is such a big issue.  In practice, I wouldn't expect
 much variation in the sets of fields requested by clients - it will either
 be the full response or a whitelisted set of fields that is the same
 across different requests.  Also, correctly implemented API caching
 already needs to respect other GET parameters anyway.

 > We're not really gaining any sort of performance benefit out of it,
 since the data has to be queried anyway, so it's purely about response
 size.

 Performance benefits should be part of the task here.  It's not hard to
 envision code that skips most of the parameter
 calculations/transformations entirely if they weren't requested as part of
 the response.  A lot of the API is already written this way: instead of
 checking `$schema['parameter']` we'd check
 `$response_fields['parameter']`.

 Even if that's not a big performance benefit generally (since most of the
 data is already being queried), there are definitely specific cases where
 we can save a lot of time by excluding fields.  The first example that
 comes to mind is `content.rendered`.  WP's content filters are expensive,
 and can even include external API requests (see also https://github.com
 /WP-API/WP-API/issues/2589).

 > I'd like to keep this ticket open though, because I do want to see that
 eventually resolved in core.

 +1

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


More information about the wp-trac mailing list