WordPress.org

Make WordPress Core

Opened 6 months ago

Last modified 7 weeks 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)

embeddable-about.patch (657 bytes) - added by herregroen 6 months ago.

Download all attachments as: .zip

Change History (11)

#1 @herregroen
6 months ago

  • Keywords has-patch added

#2 follow-up: @TimothyBlynJacobs
6 months ago

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?

#3 in reply to: ↑ 2 @herregroen
6 months 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: @TimothyBlynJacobs
6 months 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.

#5 @SergeyBiryukov
4 months ago

  • Milestone changed from Awaiting Review to 5.6

#6 in reply to: ↑ 4 @luisherranz
4 months 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 @TimothyBlynJacobs
4 months 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.

This ticket was mentioned in Slack in #core by metalandcoffee. View the logs.


8 weeks ago

#9 @TimothyBlynJacobs
7 weeks ago

We're a few days a way from Beta 1 and this hasn't seen recent activity. Going to punt since I don't think this is as simple as marking the link as embeddable and will require deeper integration with how embeds work.

#10 @TimothyBlynJacobs
7 weeks ago

  • Milestone changed from 5.6 to Future Release
Note: See TracTickets for help on using tickets.