Oembed

From BC$ MobileTV Wiki
(Redirected from OEmbed)
Jump to: navigation, search

oEmbed (short for open Embed) is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly. [1]



Specifications

Format

The most common way of resolving a URL into its oEmbed representation is to try passing it through the site itself and appending /oembed?url= but the value of the "url" parameter should be URL encoded in this case; for instance:

http://<WEBSITE>/oembed?url=

YouTube also supports this basic formula along with the format URL parameter to specify whether you want the JSON, XML or HTML rendition:

https://www.youtube.com/oembed?url=http%3A//youtube.com/watch%3Fv%3DwhAedRPe-ak&format=xml

Sometimes this is not the case, and there are additional paths, as in Flickr (which also uses request header to specify "Content-Type" for the response):

http://www.flickr.com/services/oembed/?format=json&url=https%3A%2F%2Fwww.flickr.com%2Fphotos%2Fbcmoney%2F2576389182%2F

It is also perfectly fine to host oEmbed representations that don't feed in the original URL but rather a fragment (or parameter) of it:

http://bcmoney-mobiletv.com/api/oembed/321

In this case, my own site simply requires the ID of the Video (which is the last segment of the URL, and a literal match to the VIDEO_ID field in the database). In order to render the video as oEmbed-friendly HTML, XML or JSON you simply add the format as though the ID was a file by that name (as in for VIDEO_ID "321", you would request "321.json"). The site also supports JSONp callbacks. Some may argue that this is more (or possibly even less, depending on your preferences) RESTful when measured against strictness definitions which usually suggest to have the key resources being sought identified in the URL path rather than added on as URL parameters, and leave URL parameters for optional configurations, settings or helper information; not information which is key to the request. So under this setup, you would first visit the regular video's link and discover the links marked up in the HEAD of that page, and finally request the data. This is precisely in line with the way that oEmbed was designed to work.


Discoverability

You can describe an HTML link as follows:

<link rel="alternate" type="text/html" href="http://bcmoney-mobiletv.com/api/oembed/321" title="BC$ - Gaijin (oEmbed::HTML representation)" />

Likewise for XML:

<link rel="alternate" type="application/json+oembed" href="http://bcmoney-mobiletv.com/api/oembed/321.json" title="BC$ - Gaijin (oEmbed::JSON profile)" />

Or for JSON:

<link rel="alternate" type="text/xml+oembed" href="http://bcmoney-mobiletv.com/api/oembed/321.xml" title="BC$ - Gaijin (oEmbed::XML profile)" />


Callbacks

JSONp-support is suggested, but not officially required of the specification. To call a given site/service via JSONp you typically append a parameter to the very end of the URL (either by the name "jsonp" itself, "callback", "js_callback" or something similar). The value of the parameter is the method that you want to call as the response gets received and processed. This can either be done by running "eval" directly, or chaining to a specific known method.


Security

For additional security you can lock down your oEmbed endpoints to only specific whitelisted IPs, require an API key, put it behind authentication and/or authorization mechanisms; or, for the best return on investment for time/cost to reduce exposure without investing too heavily in security, have your oEmbed Provider "URL resolution endpoint" simply support (or require) the use of a POST rather than GET request to send in the expected "url" parameter as a private message, within an HTTPS connection, this would prevent the majority of attacks such as man-in-the-middle or URL/packet sniffing.


EXAMPLE

JSON

XML

HTML

Tools

Embedly

oohEmbed

oohEmbed was the original implementation of the oEmbed spec, created by its founders and offered as a free service from 2007-2012, however the load on their servers became too much and they sold off their stake to startup (and former "web embedding tool") rival Embedly.

IFramely

iFramely has emerged as a major player in the "web embedding" market, and is now a viable alternative to Embedly, which had initially earned much criticism from "open web" advocates after shuttering oohEmbed completely and requiring legacy users to switch over to their monitored/tiered-pricing model API platform. They since added a "FREE" account level with a basic amount of daily & monthly requests included which is enough for small projects, and seems to have quelled the complaints for now. Still, it is important for there to be competitors in any niche service on the web, to avoid monopolization.

NoEmbed

Since iFramely and Embedly both require signing up for an API key, NoEmbed has emerged as a totally free and open alternative to each.

NoEmbed: https://noembed.com/ | DEMO | PROVIDERS (JSON)[4]


EXAMPLES


Parsers

Java

JavaScript

PHP



Tutorials


External Links


References

  1. oEmbed specifciation and project home: http://oembed.com/
  2. Embed-IT: http://embedit.me/ (implementation examples, also acquired by Embedly)
  3. iFramely - oEmbed implemented and enhanced in JS: https://github.com/poolby/iframely
  4. Official list of NoEmbed's integrated, oEmbed-supporting sites: https://noembed.com/#supported-sites
  5. jQuery-oEmbed and Embedly: http://blog.embed.ly/jquery-oembed-and-embedly


See Also

API | HTTP | URI