These are separate issues.
(1) [quote=“nameToReachPeople, post:8, topic:11012”]
This means that we are able to create a tag, set the src attribute to that of our JSON file and inject it into the page.
var script = $("<script />", {
src: “http://run.plnkr.co/plunks/v8xyYN64V4nqCshgjKms/data-1.json”,
type: “application/json”
}
);
$(“head”).append(script);
Although that works, it doesn’t help us much, as we have no way of getting at the data it contains.https://www.sitepoint.com/jsonp-examples/
[/quote]
What the above code snippet is talking about is gettinig a json “file”, not a script. What we need is a script to execute that will call our callback function. Trying to get a static file (as the above code snippet showed), no matter the format (json, xml, etc) will not work.
(2) I think you may be getting confused between the different concepts. GET/POST/etc HTTP verbs are part of the HTTP protocol (they are independent of headers). Headers on the other hand are properties (or name/value pairs) that are sent on every HTTP message both from the client to the server (request) and from the server to the client (response). They are 2 separate concepts.[quote=“nameToReachPeople, post:8, topic:11012”]
So does this headers in ‘limitation of jsonp’
[/quote]
Headers have nothing to do with the limitations of JSONP. The limitation is with the HTTP method. JSONP is (or should be) a read-only request (which means that you can pass parameters to the request and get a response, but you should NOT be able to change the state of the server with a JSONP request).
According to the HTTP specification, POST/PUT/DELETE allow you to CREATE/UPDATE/DELETE a resource on the server. Hence, these HTTP methods should not be allowed with JSONP (I have seen incorrect implementations of RESTful services where a GET request changes the state on the server - but this is a violation of the GET HTTP specification and is strongly discouraged). Sometimes people use a POST request as a read-only request instead of using it to CREATE a resource (for various legitimate reasons - especially security)
Some helpful (though technically in-depth) references to explain the above concepts:
(1) The HTTP 1.1 specification (has info about headers in requests and responses, different HTTP methods (GET/POST, etc) and more https://www.w3.org/Protocols/rfc2616/rfc2616.txt
(2) REST (REpresentational State Transfer) is an architectural style, and an
approach to communications that is often used in the development of Web services (https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)