The solution
The old embed model pushed complexity onto every host site. A blog or CMS had to know how Flickr, YouTube or another service structured its pages, and those rules broke whenever the provider changed markup.
oEmbed inverted the work. The provider publishes URL schemes and an API endpoint; the consumer submits the URL and gets back a JSON or XML response describing a photo, video, link or rich object.
WordPress shows why the format stuck. By 2015 it had long been an oEmbed consumer, then WordPress 4.4 also became a provider, making ordinary posts embeddable by any oEmbed consumer.
What it achieved
Ask the URL's owner how to embed it
Why it worked
A pasted URL stayed the user's only input.
Providers controlled their own embed HTML, dimensions and safety model.
Consumers could support many services through one request pattern.
WordPress adoption turned millions of sites into both oEmbed consumers and providers.
What can be applied
If every platform wants to be embedded, do not make every host parse every platform. Let the source of truth serve the embed recipe.
Aftermath
oEmbed became the quiet plumbing behind rich link previews and embeds across blogs, CMSs and media services. The important choice was not a clever parser; it was refusing to parse and asking the publisher directly.
FOLLOW THE EVIDENCE
The sources
- oEmbed raw.githubusercontent.com
- New Embeds Feature in WordPress 4.4 make.wordpress.org