WordPress.org

Make WordPress Core

Opened 11 months ago

Last modified 11 months ago

#41159 new enhancement

REST API: Add a way to determine if a request is an embedded "sub-request"

Reported by: jnylen0 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.4
Component: REST API Keywords: needs-patch needs-unit-tests
Focuses: rest-api Cc:

Description

Currently it's difficult to determine whether a request is the "root" request or a "child" embedded request due to ?_embed using multiple WP_REST_Request objects. #38964 will help a bit, but we should also add a way to directly track whether a request is part of an embed tree. Something like this:

  • $request->is_embed: boolean property indicating whether the request is a "child" embedded request
  • $request->embed_parent: WP_REST_Request object pointing to parent request, or null if none

Change History (3)

#1 @rmccue
11 months ago

Right now, we have context=embed, but that's not guaranteed to be set (it can be overridden if the URL contains a context parameter).

What's the rationale for adding this? Responses should be context-free generally, so any variation should be included in the request data (hence, context=embed).

#2 @jnylen0
11 months ago

The rationale is that an ?_embed response is not truly context-free - it's a tree of requests that are all returned at the same time, and it's occasionally useful to be able to decipher this structure.

For some background, the v1 WP.com REST API does not allow listing or fetching users or media unauthenticated, so we decided to preserve that contract when adding the WP REST API and prohibit the same operations there.

However, it should still be possible to get limited user or media item details via ?_embed. My specific use case here is to make this possible.

Currently this is achieved by watching rest_request_before_callbacks and remembering some information about the "root" request. The solution described in this ticket would be much less hacky.

#3 @jnylen0
11 months ago

Found a bug in our current approach today: rest_request_before_callbacks will be triggered (perhaps multiple times) for every rest_do_request call, but there is no filter to use at the *end* of this call chain. So any usage of rest_do_request will probably break this code.

The cleanest solution I can think of is as described in the ticket.

Note: See TracTickets for help on using tickets.