[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 mark-k):

 Replying to [comment:24 johnbillion]:

 Why do I have to have REST-API for a feature that doesn't make any use of
 it?

 <devil advocate>

 I have a simple blog. I have no desire to have it meshed up in some other
 site, but I do want to oEmbed a post in my other posts from time to time.
 I am running on a free hosting and would prefer to keep it that way, but
 the price to pay for that is that I need to optimize all aspects of my
 site, get rid of any service I do not use, therefor 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.

 This is what happens now with XML-RPC that you can not just turn off as
 there are so many services running over it (and turning off, is just at
 webserver level as loading wordpress and all the plugins and parsing the
 URLs is just too expensive).

 </devil>

 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

 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?

 Rest-API endpoint should be wp-json.php (why json? why not wp-rest?
 hopefully it can return data in XML and CSV formats as well) an oembed
 should be oembed.php. Pretty URLing for people that feel the need for it
 (probably no one as after all this is a computer to computer communication
 and computers do not care about url structure) should be easy to do at
 htaccess level or plugins that add rewrite rules.

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