summaryrefslogtreecommitdiff
path: root/old/published/Webmonkey/APIs/oembed.txt
blob: f997f3edfc809566f86d00e00f25cc52317a92ed (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
Have you ever wished you could get full multimedia embed code from a simple URL? Suppose you're building a social app that allows users to post links to images, videos or songs, wouldn't it be nice if you could turn that simple link into an embedded Flickr image or YouTube video?

Of course you can reverse engineer many of the various embed structures, but what happens when the source site of your multimedia embed changes its format or relocates the actual image? Thousands of broken links suddenly litter your site. There has to be a better way.

That's the thinking behind OEmbed, a new proposed standard for taking a URL and generating an embed link. OEmbed is the brainchild of Pownce developers Leah Culver and Mike Malone, as well Cal Henderson of Flickr and Richard Crowley of OpenDNS.

OEmbed isn't going to solve all your embedding needs since not every site supports it, but given that some big names -- like Flickr and Viddler -- have already signed on, we think others will soon follow suit.

So grab your coding tools and let's dive in to see how OEmbed can make your life easier.

== What is OEmbed ==

Put simply, OEmbed dictates a standard format where you send a URL and the host site provides the embed code. In the simplest case you would capture the URL you user has entered and then query the originating service's API to get back any additional info you need.

Here's how it works: The user enters a URL, the service (say Pownce) then queries the source of the URL (say, Flickr). The source site then sends back all the necessary information for Pownce to embed the image automatically.

The full OEmbed spec says that all requests sent to the API endpoint (Flickr in our example) must be HTTP GET requests, with any arguments sent as query parameters. Obviously any arguments you send through HTTP should be url-encoded (as per [http://www.faqs.org/rfcs/rfc1738.html RFC 1738] in this case).

The following query parameters are defined as part of the spec:

# url (required) - The URL to retrieve embedding information for.
# maxwidth (optional) - the maximum width of the embedded resource. 
# maxheight (optional) - the maximum height of the embedded resource. 
# format (optional) - the required response format (i.e. XML or JSON).

The maxwidth, maxheight parameters are nice when you're embedding content into a fixed width design and you don't want to end up with embeds that turn your carefully designed site into some horrible-looking MySpace page.

As for the response you get back from an OEmbed call, that will depend somewhat on what type of object you're interested in embedding. In general you can expect things like the type of object, the owner of the content, thumbnails and more. For full details check out the [http://OEmbed.com/ OEmbed site].

== Using OEmbed ==

Let's say you've built a content sharing site like FriendFeed. I join your site and want to post [http://www.flickr.com/photos/luxagraf/137254255/ this Flickr image of the Himalayas] using just the URL. I cut and paste the URL from my browser window to your text field and then you would query Flickr using this code:

<pre>
http://www.flickr.com/services/OEmbed/?url=http%3A//www.flickr.com/photos/luxagraf/137254255/
</pre>

The XML response you would get back looks like this:

<pre>
<OEmbed>
	<version>1.0</version>
	<type>photo</type>
	<title>Nepal-Sarangkot_12_16_05_31</title>
	<author_name>luxagraf</author_name>
	<author_url>http://www.flickr.com/photos/luxagraf/</author_url>
	<cache_age>3600</cache_age>
	<provider_name>Flickr</provider_name>
	<provider_url>http://www.flickr.com/</provider_url>
	<width>375</width>
	<height>500</height>
	<url>http://farm1.static.flickr.com/50/137254255_008f50c357.jpg</url>
</OEmbed>
</pre>

As you can see all you need to do is grab the <code>url</code> and plug that into a standard <code>img</code> tag and my photo will show up without me having to do any extra work at all.

And I know what you're thinking, if I just provide a text field for the user to paste in a URL how will I know what service to query? There's two obvious ways you can handle that. One would be to provide a drop down menu that allows users to specify the source of the link. The other would be the just parse the link with some [http://www.webmonkey.com/tutorial/Regular_Expressions_Tutorial Regular Expressions] [http://www.webmonkey.com/tutorial/Use_Regex_in_Perl magic] and handle it transparently.

If you have other ideas, be sure to add them.

== Getting more complex ==

That's all well and good, but what about more complex examples like video? This is actually where OEmbed shines -- no more filling in some complex embedding template that's liable to break whenever something changes on the source site.

This time we'll use Viddler as an example. Let's say the visitor to our sharing site wants to embed [http://www.viddler.com/explore/RickRoll/videos/2/ this video]... they copy the URL and paste it in our form text field and then we query Viddler's OEmbed URL. But this time we'll add a parameter to make sure the embedded video is 400 pixels wide. 

The query code would look like this:

<pre>
http://lab.viddler.com/services/OEmbed/?url=http%3A%2F%2Fwww.viddler.com%2Fexplore%2FRickRoll%2Fvideos%2F2%2F&width=400&format=xml
</pre>

Viddler will then return this XML response (or if you change the <code>format</code> parameter to JSON, you could get a JSON response):


<pre>
<?xml version="1.0" encoding="UTF-8"?>
<OEmbed>
	<version>1.0</version>
	<type>video</type>
	<width>400</width>
	<height>342</height>
	<title>Rick Roll Muppets Version</title>
	<url>http://www.viddler.com/explore/RickRoll/videos/2/</url>
	<author_name>RickRoll</author_name>
	<author_url>http://www.viddler.com/explore/RickRoll/</author_url>
	<provider>Viddler</provider>
	<provider_url>http://www.viddler.com/</provider_url>
	<html><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="400" height="342" id="viddlerplayer-4310bfba"><param name="movie" value="http://www.viddler.com/player/4310bfba/" /><param name="allowScriptAccess" value="always" /><param name="allowFullScreen" value="true" /><embed src="http://www.viddler.com/player/4310bfba/" width="400" height="342" type="application/x-shockwave-flash" allowScriptAccess="always" allowFullScreen="true" name="viddlerplayer-4310bfba" ></embed></object></html>
</OEmbed>
</pre>

As you can see, the last element of the response, the <code>html</code> node, gives us the embed code and keeps the video constrained to the dimensions we specified. It doesn't get much easier than that.

Viddler has even put together a cool little sample app that [http://lab.viddler.com/services/OEmbed/form.php shows OEmbed in action].

=== Security Note ===


When you're creating a site that's going to display HTML (as with video embeds), there's always the potential for XSS attacks from the site providing the code. At the moment all the site offering OEmbed are reputable, but that may not always be the case. To avoid opening your site up to XSS attacks, the OEmbed authors recommend displaying the HTML in an iframe, hosted from another domain. This ensures that the HTML cannot access cookies from the consumer domain.


== Sky's the Limit ==

OEmbed isn't just for developers either. At the moment no one has released any, but if you wrapped OEmbed as a WordPress or Movable Type Plug-in, even posting content on your own site would be considerably easier.

If happen to be working with the Django web framework there's already a nice set of [http://code.google.com/p/django-OEmbed/ OEmbed template tags] up on Google code. The project allows you to do things like this in your Django templates:

{% OEmbed %}
http://www.flickr.com/photos/luxagraf/
{% endOEmbed %}

If you know of other implementations, add them here.

== Why We Love OEmbed ==

There's a bunch of ever-changing social web specs out there promising all sort of things, from easier logins though OAuth and OpenID to Google and Facebook's widget platforms, but where most of the promises remain unfulfilled, OEmbed is here today and it just works.

Obviously it's missing some key sites like YouTube or Picasa, but hopefully it won't be long before OEmbed becomes a standard part of every successful web API.