The callback is a function YOU’VE defined in your own code. The jsonp server will wrap its response with a function call named the same as your specified callback function.
What happens it this:
1) Your code creates the JSONP request, which results in a new <script> block that looks like this:
<script src="http://server2.example.com/RetrieveUser?UserId=1234&jsonp=parseResponse"></script>
2) That new script tag is executed by your browser, resulting in a request to the JSONP server. It responds with
parseResponse({"Name": "Foo", "Id" : 1234, "Rank": 7});
3) Since this request came from a script tag, it’s pretty much EXACTLY the same as if you’d literally placed
<script>
parseResponse({"Name": "Foo", "Id" : 1234, "Rank": 7});
</script>
into your page.
4) Now that this new script has been loaded from the remote server, it will now be executed, and the only thing it will do is a function call, parseResponse(), passing in the JSON data as the function call’s only parameter.
So somewhere else in your code, you’d have:
function parseResponse(data) {
alert(data.Name); // outputs 'Foo'
}
Basically, JSONP is a way of bypassing the browser’s same-origin script security policy, by having a 3rd party server inject a function call directly into your page. Note that this is by design highly insecure. You’re depending that the remote service is honorable and doesn’t have malicious intent. Nothing stops a bad service from returning some JS code that steals your banking/facebook/whatever credentials. e.g…. the JSONP response could’ve been
internalUseOnlyFunction('deleteHarddrive');
rather than parseReponse(…). If the remote site knows the structure of your code, it can perform arbitrary operations with that code, because you’ve opened your front door wide-open to allow that site to do anything it wants.