[wp-trac] [WordPress Trac] #52992: REST API: Avoid unnecessarily preparing item links

[WordPress Trac]

#52992: REST API: Avoid unnecessarily preparing item links
-------------------------+-----------------------------
 Reporter:  dlh          |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  REST API     |    Version:  4.7
 Severity:  normal       |   Keywords:  has-patch
  Focuses:               |
-------------------------+-----------------------------
 The bundled REST API controllers currently prepare links for each item in
 a REST response regardless of whether the links will appear in the
 response or are needed to fulfill an `_embed` request.

 For example, when responding to the request from the block editor for
 available hierarchical terms:

 `?per_page=100&orderby=name&order=asc&_fields=id,name,parent&_locale=user`

 `WP_REST_Terms_Controller` will call `prepare_links()` for all found terms
 even though the `_links` property is omitted from each, adding unnecessary
 processing that delays the response to the client.

 Based on [https://wordpress.slack.com/archives/C02RQC26G/p1617222154014800
 a discussion in the core Slack], the change proposed for this ticket
 would:

 1. Include `_links` by default in
 `WP_REST_Controller::get_fields_for_response()`, and include `_embedded`
 if the request object includes the `_embed` parameter. As discussed in
 Slack, these fields are included as a convention. The fields aren't
 typically included in the item schema, and because `prepare_links()` isn't
 a method defined on the base controller, it isn't possible for the
 controller to know before the response is prepared whether it will
 actually include links.

 2. Wrap the calls to `prepare_links()` and `add_links()` in each of the
 bundled controllers in checks for whether the `_links` field or
 `_embedded` field is included in the response.

 Lastly, during the Slack discussion, Timothy asked:

 > Do you think we should bother checking for each individual link? We
 could theoretically do rest_is_field_included( '_links.self' ), etc...

 I've opted to not do this in the current patch, simply to avoid the
 complexity of modifying the `prepare_links()` signatures across the
 various controllers to accept the requested fields or the request object,
 but I'm happy to do so if desired.

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