[wp-trac] [WordPress Trac] #34207: Leverage the REST API structure for the oEmbed endpoint

[WordPress Trac]

#34207: Leverage the REST API structure for the oEmbed endpoint
--------------------------------------+---------------------
 Reporter:  swissspidy                |       Owner:  rmccue
     Type:  task (blessed)            |      Status:  closed
 Priority:  normal                    |   Milestone:  4.4
Component:  Embeds                    |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by rmccue):

 Replying to [comment:25 mark-k]:
 > Why do I have to have REST-API for a feature that doesn't make any use
 of it?

 It ''does'' make use of it, hence the point of this ticket. It replaces
 the JSON handling in oEmbed, and uses well-tested infrastructure instead
 of duplicating it.

 > naturally I want to block the REST-API. But now (ok, in 4.5 when there
 will be actual active end points) I can not do that because it will bring
 down oEmbed.

 In future versions, we'll likely start using the REST API instead of
 certain `admin-ajax.php` calls in the admin as well (with fallbacks for
 people without JS). I'd suspect that disabling the REST API will cause
 problems (or at least a worse experience) in the future.

 > For me this is violation of software engeneering rules
 > 1. Separation of interests. If oEmbed do not depend on REST API, then it
 should not depend on it in any way

 In the previous code, there was duplication of things already in the API,
 including JSONP handling (which has security implications if we need to
 duplicate that code, since it increases the potential attack surface).
 Combining the two makes a lot of sense.

 > 2. (this is really an rest-api issue) No hardcoding of anything that do
 not have to be hardcoded in a name space where you do not expect things to
 be hardcoded. It is one thing when a plugin wants to use a specific URL
 structure as it will most likely fail at activation or right after it, but
 a wordpress upgrade that breaks plugins? How should anyone handle it?
 where is the backward compatibility promised by core to convince people to
 auto upgrade?

 `wp-json` isn't hardcoded, as @johnbillion noted; you can filter it, and
 clients are expected to work automatically with this via [http://v2.wp-
 api.org/guide/discovery/ the discovery process].

 I'm not sure what backwards compatibility you're expecting that we're
 breaking here?

 > Rest-API endpoint should be wp-json.php

 We've tried that in the past, but there are various problems with having
 it as a real PHP file that are handled quite nicely by using rewrites
 instead. For those without rewrites, there's already a fallback.

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