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 XDomain?
Cheers ,
Andrew
Yes.
Luckily simple idempotent informational GET requests are the most common use case for cross-domain JSON.
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.