Granted, if (as I and so many others hope) RESTfulness and Atom permeation on the web becomes much more well established (approaching ubiquity), this would be dead easy to define further down the line. (Albeit not having done it initially maintains the fragmented web data infrastructure, already in dire need of unification.)

(Now, on to building a bridge from Atom to RDF for the 3.0 web. :) Best regards.)

Stephen: The main problem with what you are describing is that we wanted to avoid the need to gather the entire document. Though I agree this could have been built ontop of other standards.

Thanks for your feedback everyone – working together like this in a conversational way can only make things better.

@Mike, may I suggest you add a little paragraph to oembed.com explaining why you chose to do it in this way (easy of implementation with static resources, templating systems, existing codebases etc.)? It might save you having to repeatedly justify yourself to folks like us :)

However, I am so enamourmed with oEmbed in general, that I just want the service to succeed and am willing to accept a less than perfect implementation :)

Rather than specify a custom content type, you can use parameters. You can even specify version this way:

Accept: application/json;oEmbed=1.0

Service discovery can work an HTTP way, too. HEAD requests to specific resources are designed to provide this sort of information without requiring downloading large quantities of content:

Alternates: {”" 0.0 {type application/json} {x-oEmbed 1.0}}, {”" 0.0 {type text/xml} {x-oEmbed 1.0}}

I don’t think the template argument is the right one. No-one’s writing static templates by hand and using them in isolation; they’re parsed by servers and services that can handle parsing HTTP headers. A WordPress (or equivalent) plugin does all the work for you anyway.