JSONP Implications with true REST

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 were 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开发者_StackOverflow社区 XDomain?

Cheers ,

Andrew

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.

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.)

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'.

Apologies ahead of time if replying to an old post is bad form on SO.

@bobince

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.

So true RESTful is not possible with JSONP due to a lack of PUT, DELETE and POST verbs. However, many JSONP APIs still allow writes. I vaguely recall it being possible in Facebook's OAuth JSONP API.

Regardless, it would seem that a faux RESTful JSONP API could be achieved by assuming server-side if both "callback=" AND "method=" are present in the URL and method is one of GET, POST, DELETE or PUT then it will be treated as though it were a true REST request.

This breaks the single URL for a single resource paradigm of REST as callback will change nearly every time, and even if it remained constant, there would be 4 URL representations, one for each method. So my question is, what are the ramifications of this break from the RESTful paradigm, specifically regarding your concerns of "stray, leakable, cacheable GET requests" with potentially "[accidental] side-effects"?

A emerging technique for handling CORS (Cross Origin Resource Sharing) is using HTTP Access Control. An informative article on it can be found at on the Mozilla Developer pages, on an article on the Kendo Blog, and on the W3 Site

In summary, on the server side, you'll need to return a couple of Access-Control headers which help control access. For simple GET/POST requests, you can simply return an Access-Control-Allow-Origin header, for more complex requests with other methods you'll need additional headers, which can be found on the above resources.