Friday, May 9th, 2008
oEmbed makes embedding third party videos and images a breeze
Category: Announcements
, Standards
Flickr, Viddler, Qik, Pownce and Revision3 are the first services to support oEmbed, an easy way to allow embeding media from a certain URL in a third party site.
From the oEmbed site:
oEmbed 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.
This means that if you for example find a nice photo on flickr, you can take the URL and easily turn it into embed-able data:
Original URL: http://flickr.com/photos/codepo8/2475016321/
oEmbed URL: http://flickr.com/services/oembed?url=http://flickr.com/photos/codepo8/2475016321/
Result:
-
<oembed>
-
<version>1.0</version>
-
<type>photo</type>
-
<title>? too much myspace error</title>
-
<author_name>codepo8</author_name>
-
<author_url>http://www.flickr.com/photos/codepo8/</author_url>
-
<cache_age>3600</cache_age>
-
<provider_name>Flickr</provider_name>
-
<provider_url>http://www.flickr.com/</provider_url>
-
<width>500</width>
-
<height>375</height>
-
<url>
-
http://farm4.static.flickr.com/3128/2475016321_982666ec95.jpg
-
</url>
-
</oembed>
You can define the output format and the maximum width and height with URL parameters:
oEmbed URL:
Result:
-
{
-
version: '1.0',
-
type: 'photo',
-
title: '? too much myspace error',
-
author_name: 'codepo8',
-
author_url: 'http://www.flickr.com/photos/codepo8/',
-
cache_age: '3600',
-
provider_name: 'Flickr',
-
provider_url: 'http://www.flickr.com/',
-
width: '100',
-
height: '75',
-
url: 'http://farm4.static.flickr.com/3128/2475016321_982666ec95_t.jpg'
-
}
Supported formats for responses so far are photo, video, link and rich.
Nice to have a common api for embedding content! Hope to see more providers in the future.
Despite the label the first example shows XML, not HTML code, and in fact oEmbed returns either XML or JSON.
This seems bad for Google juice. Will Google see these references and links?
@dylangreene: I expect that sort of depends whether you’re snagging the data server-side or client-side. I figure the way I’ll use this is to get the data client-side to build and then use the same routine server-side (with cache) to ensure the content stays synced after it’s committed by a user.
It’s may be very useful standard, but one important thing is missing — a something like auto-discovery. “Providers must specify one or more URL scheme and API endpoint pairs” — but WHERE providers must specify it?
davidmz: we’re working on the spec for auto-discovery at the moment. Expect to see it published very shortly.
In my opinion, if RESTful principles are followed, the oEmbed API endpoint (and hence auto-discovery) is not required at all. I’ve blogged my thoughts here:
http://www.backdrifter.com/2008/05/09/oembed-fail-represent-restfully/
I’d be interested in further discussion.
The oEmbed site says that “JSON responses must contain well formed JSON”, but the examples given are all invalid JSON. Oops. :-)