Discoverable JSON oEmbed URLs return JSON-P responses

I see I'm currently returning

    self.set_header("Content-Type", "application/json")

Which I thought was the right way to do it. Does it break your app if it's content-type json?

My app is looking for the type="application/json+oembed" link and expecting a JSON body with Content-Type: application/json. As JSON-P responses are JavaScript and don't parse as JSON because of the function call they include, my app breaks if you return JSON-P instead of JSON.

Did someone want the JSON-P version to be discoverable? (How can they know what function to use without knowing to look for "jsoncallback" in the URL's query string? Or is that part of some standard discoverability thing?) If you do want to include both, I would expect to see:

<link rel="alternate"
      type="application/json+oembed"
      href="http://mlkshk.com/services/oembed?url=http%3A//mlkshk.com/p/OLY"
      title="They finally plowed the Embarcadero shared by dreamersawake">
<link rel="alternate"
      type="application/javascript+oembed"
      href="http://mlkshk.com/services/oembed?url=http%3A//mlkshk.com/p/OLY&jsoncallback=jsonp1298766601"
      title="They finally plowed the Embarcadero shared by dreamersawake">

with a Content-Type: application/json when there's no "jsoncallback" and a Content-Type: application/javascript when there is.

Using application/javascript for JSON-P I mainly got from http://stackoverflow.com/questions/111302/best-content-type-to-serv... .

Got it. I will do this.

I actually got mine from Flickr's implementation. But thinking now how we're about to do oEmbed for Youtube and Vimeo, I don't expect or want JSON-P.

Yay!

Really now that there's some API I should switch to use that, but haven't yet.

We have some changes coming to the API in a bit. Perhaps this week. The way the friend shake works is inefficient, we're going to make it work like the web side does with "before" and "after" requests.