JSONP Implications with true REST

Question

From my understanding JSONP can only be achieved using the GET verb. Assuming this is true which I think it is, then this rules out core compliance with true REST in which you should make use of different verbs i.e. GET,PUT,POST,DELETE etc... for different and specific purposes.

My question is what type of barriers am I likely to come up against if I where to say allow updating and deleting of resources using a JSONP service using a get request.

Is it better practice to offer a JSON service and state that the user will need a server side proxy to consume using JavaScript XDomain?

Cheers ,

Andrew

Answer 1

JSONP is very limited, as what it does it include the script using the <script> tag and then do a callback to some function that processes.

Personally, I prefer a true service. Writing a server-side proxy is not that difficult, and enables you to have more control over it (like time-outs, error handling, other types of requests etc.)

Answer 2

From my understanding JSONP can only be achieved using the GET verb.

Yes.

Luckily simple idempotent informational GET requests are the most common use case for cross-domain JSON.

this rules out core compliance with true REST in which you should make use of different verbs i.e. GET,PUT,POST,DELETE etc

Yes.

I'm not too bothered with ‘complying’ with REST as an abstract standard, but it's a real concern if stray, leakable, cacheable GET requests can accidentally have side-effects.

There are strategies you can use to reduce the likelihood of this sort of problem, such as requiring a per-API-user and/or one-time-use submit-key as a parameter to allow the action to go ahead. If you are allowing write access to an API via JSONP you will need to be thinking about this sort of thing anyway, to prevent XSRF attacks.

Answer 3

JSONP is a security boundary workaround (ajax calls only allowed on same domain). As stated it is very limited and can only be used for read-only (HTTP GET through html script/src includes). For that it eases integration and mashups without the need to have a server-side proxy making the real api HTTP request.

But I would never break my Restful api just to allow jsonp do to do any write-actions (like delete, create, write).

Another big drawback is security: JSONP calls are triggered by the browser and username/password transmission cannot work (it would be plainly visible inside the request). For many apis disabled authentication for write actions is a no-go. Even if you work with server generated one-time tokens this is dangerous because you can malicously misuse it by using tools like 'curl'.