[wp-trac] [WordPress Trac] #42061: Add new utility function for checking if the current request is a REST API request.

[WordPress Trac]

#42061: Add new utility function for checking if the current request is a REST API
request.
------------------------------------+-----------------------
 Reporter:  lots.0.logs             |       Owner:  flixos90
     Type:  enhancement             |      Status:  assigned
 Priority:  normal                  |   Milestone:  5.0
Component:  Bootstrap/Load          |     Version:  4.9
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  rest-api
------------------------------------+-----------------------
Changes (by flixos90):

 * keywords:  has-patch => has-patch dev-feedback
 * owner:  (none) => flixos90
 * status:  reopened => assigned


Comment:

 As usual, this is more complicated than it may seem at first glance. Other
 than AJAX and Cron, which are controlled by constants, REST is controlled
 by a query variable, meaning it relies on the current request to be
 parsed. The `REST_REQUEST` constant is only set for an easy check, but is
 not available from the beginning of the request's lifecycle.

 It is therefore impossible to detect a REST request before the
 `parse_request` action, at least with the means currently in place. That
 action is triggered rather late, after `init`, `wp_loaded` etc.

 There is actually a bug in core which doesn't take the above into account:
 in `wp_debug_mode()`, it is checked whether the current request is a REST
 request in order to not display errors in such a case. However, this check
 will always result in `false`, since the function is executed even before
 most of WordPress files are even loaded. Therefore, currently REST API
 responses will still be messed up by debugging messages if enabled. This
 could be fixed in a separate issue though, depending on what we decide
 here.

 I see two possibilities:
 * We could embrace the current functionality, relying on the query
 variable and introduce the function in a way that is triggers
 `_doing_it_wrong()` if called too early. In that case, it should be named
 differently from the existing `wp_doing_ajax()` and `wp_doing_cron()`, to
 indicate its different behavior (I suggest `wp_is_rest_request()` because
 in WordPress terms that connects it to the request which is associated
 with parsing the current request).
 * We could find a way to detect a REST request through another way and aim
 for making the process similar to AJAX and Cron so that it can be detected
 really early. In that case, the function could also be named accordingly,
 `wp_doing_rest()`.

 I'm in favor of the first alternative, and this is what I implemented in
 [attachment:"42061.diff"]:
 * It introduces `wp_is_rest_request()` in `wp-includes/functions.php`. No
 point to put it in `wp-includes/load.php` under these circumstances.
 * If `parse_request` has not been executed yet ''and'' `REST_REQUEST` is
 not set (this check would allow custom setups to still set it early), but
 the function is called already, a `_doing_it_wrong()` is triggered.
 * The check for a REST request in `wp_debug_mode()` has been removed,
 since it doesn't do anything. Since I adjusted that line anyway, I also
 fixed a direct check of `WP_INSTALLING`, which should instead rely on
 `wp_installing()`.
 * Other checks of `REST_REQUEST` has been adjusted as well, and the
 additional check in `wp-admin/includes/ms.php` is something I detected
 during #43751 (it could currently simply kill REST requests).

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