The official standard for the Content-Type header value when returning json is "application/json". Can you please change your responses to use this header value instead of "text/javascript"? Existing tools look for the standard header and don't automatically parse the JSON b/c it's not there.
Hi aggiekevin,
Could you let us know what libraries/tools you are using that rely on the content type? We currently know that jQuery (not using jsonp) does this and I'm curious to know what other libraries also do this.
The original intention, misguided or not, for having the content type as text/javascript was for it to be easier to explore the API in your browser before diving into code. Some browsers, like Firefox and IE8, download the json response when the content type is set to application/json and by setting it to text/javascript, it can be viewed in plain text in those browsers.
You are right that the correct return type should be "application/json". We are very much open to changing it, but we have two conflicting goals here:
1) You should be able to easily explore the API in your browser
2) We should follow the json spec, RFC 4627, for our response - The correct return type for json is "application/json"
At the end of the day, we want to make the API easy to work with. So let us know if our current decision to serve text/javascript is causing any undue pain or blocking development. What workarounds or compromises have you had to make? This information will help us to guide the changes we consider on our API roadmap.
Was this ever resolved? I'm using RestKIT on the iPhone and the returned response body is javascript and not json. I would expect that when I make an API call with /movies.json it's going to return JSON!
If you can't fix this ASAP is there at least a workaround? Take the response body string and re-encode it as JSON??
The official standard for the Content-Type header value when returning json is "application/json". Can you please change your responses to use this header value instead of "text/javascript"? Existing tools look for the standard header and don't automatically parse the JSON b/c it's not there.
Thanks!
Message edited by aggiekevin 2 months ago
Steve N. – 2 years ago
Hi aggiekevin,
Could you let us know what libraries/tools you are using that rely on the content type? We currently know that jQuery (not using jsonp) does this and I'm curious to know what other libraries also do this.
The original intention, misguided or not, for having the content type as text/javascript was for it to be easier to explore the API in your browser before diving into code. Some browsers, like Firefox and IE8, download the json response when the content type is set to application/json and by setting it to text/javascript, it can be viewed in plain text in those browsers.
You are right that the correct return type should be "application/json". We are very much open to changing it, but we have two conflicting goals here:
1) You should be able to easily explore the API in your browser
2) We should follow the json spec, RFC 4627, for our response - The correct return type for json is "application/json"
At the end of the day, we want to make the API easy to work with. So let us know if our current decision to serve text/javascript is causing any undue pain or blocking development. What workarounds or compromises have you had to make? This information will help us to guide the changes we consider on our API roadmap.
Thank you,
-Steve
darkonesS – 1 year ago
Hey Steve,
Could you do something like :
Regards.
horseshoe7 – 8 months ago
Was this ever resolved? I'm using RestKIT on the iPhone and the returned response body is javascript and not json. I would expect that when I make an API call with /movies.json it's going to return JSON!
If you can't fix this ASAP is there at least a workaround? Take the response body string and re-encode it as JSON??
jeffAwesome – 2 months ago
Hey guys i'm running into very much the same issue. I'm not able to use this api at all on my application because of this issue.