OEmbed a Good Idea, But it Sucks

Today I heard about OEmbed, my first reaction was to implement it, of course ! The idea is to define a way of providing a page preview. Say you post a link on a microblog or something, the said microblog or something can visit the link, figure out what the resource is to obtain the preview, or OEmbed version (embeddable), and then chose to display that preview. Neat.

For it to work you need what they call an OEmbed provider, A provider is another service that will return the summary (JSON, XML or HTML). Apparently the client could specify the format they want the reply in.. To get the provider it seems there is a list of "well known providers" !! This means you take your link and ask the provider (another url) to transform your initial link into an OEmbed formatted something.... . FAIL !!11!!1.

Another thing is discovery, now this is a good thing, obviously, to put in the header a link to get the OEmbed version of the page, like RSS maybe ? The stupid part is that it requires that the link contains a url GET parameter, that supposes that instead of just providing a link to a OEmbed happy version of the page you MUST provide a "OEmbed provider link" that will take the URL of the page you are visiting, parse it and.. . BROKEN.

Why can't it just be an alternate link ?

Of course there are 3rd party providers now, and that is exactly what we don't need... It's so simple to generate a JSON or XML file that why would anyone ever think of a 3rd party web site whose role it would be to scrape your site to then provide a.. .OMG BROKEN.

As the idea is good but the implementation sucks why not simplify it, lets say we either use HEAD, like Jared Hanson and Vitorio Miliano pointed out in May 2008, or just use an alternate link a la RSS feed. If it's simple and easy for everyone to implement it will work.