content negotiation

[Lucas Gonze]

I apologize if this has been discussed in the past. This is a thought inspired by reading the old thread about a version 2.

The Oembed protocol exposes the URL of an oembed resource by having a link[@type="application/json+oembed"] or link[type="application/xml+oembed"] in an html document header. To find the header a third party must fetch and parse the HTML, then issue a follow up request to the linked resource.

An algorithm based on content negotiation would be faster at run time and easier to implement.

To implement this, a third party which is beginning the process of finding the oembed resource would set the application/xml+oembed and application/json+oembed types in the Accept request header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1):

If an HTTP client normally sends the following request header:
        Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

Instead it would send this:
        Accept: text/html; q=1.0, text/*; q=0.91, application/xml+oembed; q=0.9, application/json+oembed; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1

If the host had implemented support, it would immediately return the oembed resource rather than the HTML resource. The requesting host would then not have to parse the HTML adn make a second request for the linked oembed resource.

This method is backwards compatible. No existing implementations will be harmed.

This method requires no new protocol or specification. It is already legal and fully documented. All that needs to happen is adoption. To generate adoption the work is evangelism.