Discoverable JSON oEmbed URLs return JSON-P responses
Reported by Mark Paschal | February 26th, 2011 @ 06:30 PM
What I did:
- Programmatically discovered the alternate resource of type
"application/json+oembed" for permalink /p/ pages.
- Requested the alternate resource.
- Parsed the alternate resource as JSON.
What I expected to happen:
Tasty picture goodness to pop out.
What actually happened:
The response body can't be parsed as JSON. This may be expected by a human who sees the oEmbed URL is now of the form:
http://mlkshk.com/services/oembed?url=http://mlkshk.com/p/OLY&j...
with a JSON-P callback function name provided, which is in fact used in the resource, making it JSON-P instead of JSON. (Similarly the internet seems to think JSON-P responses should have an "application/javascript" Content-Type.)
Comments and changes to this ticket
-
Andre Torrez February 27th, 2011 @ 03:26 PM
- State changed from new to open
Hi Mark.
I was unsure about which way to go with that. If you leave the jsonp off:http://mlkshk.com/services/oembed?url=http://mlkshk.com/p/OLY
You do get it without the enclosing function name. Should I simply provide two resource types?
I will make it return application/javascript in a few seconds.
-
Andre Torrez February 27th, 2011 @ 03:36 PM
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?
-
Mark Paschal February 27th, 2011 @ 05:14 PM
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... .
-
Andre Torrez February 27th, 2011 @ 05:21 PM
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.
-
Mark Paschal February 27th, 2011 @ 05:34 PM
Yay!
Really now that there's some API I should switch to use that, but haven't yet.
-
Andre Torrez February 27th, 2011 @ 05:35 PM
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.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
MLKSHK it's fun for the whole family.