Opened 4 years ago
Last modified 4 years ago
#50409 new enhancement
REST API about links should be embeddable.
Reported by: | herregroen | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.5 |
Component: | REST API | Keywords: | needs-patch |
Focuses: | rest-api | Cc: |
Description
Currently the about
links in the REST API aren't embeddable using the ?_embed=true
parameter.
Most likely cause I can think of is that, by default, this route ( wp/v2/types/$post_type
) doesn't contain much information and as such there's likely no need for it.
However plugins can add their own custom fields to post types that would be added to this route. Currently if one wishes to fetch that data an additional request would have to be made as it's not possible to embed the data in a previous request.
Making the about link embeddable would give the option to consumers of the REST API to also easily fetch custom fields on post types without requiring an additional request.
This change would be extremely minimal as it'd only require adding 'embeddable' => true
, on line 1864 in wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
.
Attachments (1)
Change History (11)
#3
in reply to:
↑ 2
@
4 years ago
Replying to TimothyBlynJacobs:
Let's make sure this gets added to the terms
about
link as well so we're consistent.
My hesitation for this is that it would be identical information for each and every post returned in the collection, ie it doesn't vary based on the post object's content. If you're retrieving a single post you'd always be able to make a request at the same time to the
types
route, no?
Only if you're passing the _embed
parameter every time, in which case you may also receive other information in duplicate. And even then, only if you're passing the true
value to have everything embedded as opposed to selecting specific fields you want.
My current feeling is that passing ?_embed=true
you're essentially saying I want to know everything about this post, to which I feel the post type information belongs.
If the intent is to limit duplicate information then the default, not passing any _embed
value or even passing specific _embed
values covers that.
#4
follow-up:
↓ 6
@
4 years ago
in which case you may also receive other information in duplicate.
In those cases the information may be duplicate information but only if the property is identical in each post and in this case you cannot possibly know what that information will be since it depends on the post object.
In other words, if embedding wasn't a thing, and you wanted to fetch the post author's information you'd first have to request the post object, find the author
property and then make a new request to wp/v2/users/<author>
.
My point about this case is that since the information belongs to the post type, it would necessarily be identical for every post and you already know where to find that information. You can make a request at the same time to wp/v2/types/<cpt>
as you make a call to wp/v2/<cpt>/<id>
.
A nice enhancement would be to allow for marking links as embeddable but not having them embedded by default, but if you requested the relation specifically with _embed=rel
it would be included. We could probably just support that for all internal links.
#6
in reply to:
↑ 4
@
4 years ago
I think that if the duplication of embedded resources were not an issue, there won't be any doubt that the type
information belongs to the "related resources" of a post. For that reason, I think it shouldn't be treated differently just because of the high duplication ratio.
On the other hand, I think the REST API should provide a general solution to avoid duplication of embedded resources because it will benefit many other cases, not just this one. There are a lot of resources that also have high duplication ratios, like authors or common tags and categories.
Maybe a solution for that could be to expose a top _embedded
field when combining the _embed
and _envelope
queries, where the embedded resources would be properly normalized. But I guess this is probably not the place to discuss this :)
#7
@
4 years ago
- Keywords needs-patch added; has-patch removed
@luisherranz I think that's an interesting idea, but I agree best described in a separate ticket.
To solve this issue, I'd take a look at allowing opt-in embedding to any internal links.
Let's make sure this gets added to the terms
about
link as well so we're consistent.My hesitation for this is that it would be identical information for each and every post returned in the collection, ie it doesn't vary based on the post object's content. If you're retrieving a single post you'd always be able to make a request at the same time to the
types
route, no?