The distinction comes into play when you are using JavaScript to parse the reply and update the page. If you are using a JSON API in another Rails application (or PHP, or any other server-side language) then you don't need to worry about this at all.
JavaScript interpreters all enforce a Same Origin policy, which says that a script can only access data from a site that is in the same domain, subdomain, and port as itself.
When you control both endpoints, and they don't pass the Same Origin tests, and you don't want to set up CORS, JSONP allows you to create a callback function to modify the page based on "foreign" JSON content. If you control both endpoints, and you want to set up CORS, then a traditional JSON reply is nicer, because you only rely on that endpoint to send you well-formed data, nothing else. JSONP exposes your implementation details to the API sender, and counts on that sender to reply with the callback that you indicated in your request within the body of the JSON response.
The HTML site containing these lines:
https://github.com/walterdavis/api/blob/master/index.html#L117-L130 shows off both JSON (CORS) and JSONP (no CORS needed -- although my example Rails app has rack-cors installed -- it worked before I did that). Those lines are the entirety of the JSONP scheme -- one function, which takes the JSON reply from the server as its only argument, and one injected script tag to kick it all off.
Walter
> To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/fbfbc179f0806a619f8ec053f1c10e4c%40ruby-forum.com.