Opened 7 years ago
Closed 4 years ago
#41159 closed enhancement (wontfix)
REST API: Add a way to determine if a request is an embedded "sub-request"
Reported by: | jnylen0 | Owned by: | |
---|---|---|---|
Milestone: | 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, ornull
if none
Change History (4)
#2
@
7 years 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
@
7 years 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.
#4
@
4 years ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
I agree with @rmccue that each of these requests should be context free. The variation is entirely controlled by setting context=embed
. I also don't think we should encourage users to use the fact that the given request is an embed in lieu of proper permission checks. It also breaks the contract that you should be able to follow an embedded link and get results if the results are only accessible when doing an ?_embed
request.
Right now, we have
context=embed
, but that's not guaranteed to be set (it can be overridden if the URL contains acontext
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
).