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

WordPress Trac noreply at wordpress.org
Sun Jan 24 20:02:49 UTC 2021


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

 * owner:  flixos90 => TimothyBlynJacobs


Comment:

 As @flixos90 mentioned, checking if this is a REST API request "properly"
 requires parsing rewrite rules. As such, if we want to support checking
 this early, we essentially need to duplicate some of the logic in
 `WP::parse_request`. I've attached a PR that does this and works in my
 testing so far with the built-in dev environment for.

 - `http://localhost:8889/wp-json`
 - `http://localhost:8889/index.php/wp-json`
 - `http://localhost:8889/index.php?rest_route=/`
 - `http://localhost:8889/?rest_route=/`

 Just because we are replicating the logic doesn't mean this guarantees
 correctness since the query could be modified with a number of hooks that
 would change behavior and the rewrite rules could be setup to be something
 completely different from `rest_api_register_rewrites`. I think there may
 also be issues if `WP_Rewrite::$index` is overwritten and the function is
 called before `WP_Rewrite` is setup.

 There is also the handling for when the REST API is accessed without
 pretty permalink. An issue here is that essentially we are trying to
 detect if `wp` will be called, but there is no way to guarantee `wp` will
 or will not be called before it is called. I implemented this by checking
 for the `WP_USE_THEMES` constant which works for vanilla core AFAICT, but
 again customized setups might have issues.,

 However, I think we should be able to make it work for all "out of the
 box" server setups, ie where those advanced customizations haven't been
 made. If a site is making those adjustments, they could use the filter to
 provide more accurate detection.

 If we want to continue with this, it'd need to be manually tested in a
 number of different server environments. And we'd have to be careful about
 usage. I'd think Core should probably only use the function post
 `parse_request`. I think it is still useful to allow for it to be called
 prior to that for usage in plugins.

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


More information about the wp-trac mailing list