When accessing web services through javascript, you are limited to your single domain because of the extra security measurers with cross-domain policy stuff. jQuery supports the JSONP approach to solving this problem. Essentially it adds call back support to the web service. So the webservice itself returns back a function object with the JSON data inside of the function. Then jQuery modifies the DOM and inserts the returned object back as a script object. More info: http://en.wikipedia.org/wiki/JSON#JSONP
myCallback({ "hello" : "Hi, I'm JSON. Who are you?"})
This would allow you to use Servoy web services with jQuery. I know the rest_ws plugin is open source, so if I make the change, can I submit a patch for this to be included as a standard part of the plugin, or would you prefer this be done as a separate plugin?
I’d say that if it can be added to the existing plugin, without breaking the existing implementation, it’s best to include it into the existing plugin.
Attached is a signed build implementing JSONP if anyone wants to test. I have a working example using jQuery at my website
Also a patch is attached. (.patch attachments not allowed to be uploaded, so is .txt)
The only actual needed changes were in RestWSServlet class. However it looks like there were some pending changes in the RESTWSPlugin class in the getJSONSerializer() function that I had to revert back because it was breaking the usage of the plugin.
jcompagner:
so the only change is the json.toString() into that if that first checks for the callback parameter right?.
Yes
jcompagner:
The parameter name is now hardcoded. But is that the “spec” of JSONP? or can it be anything?
So should we make that a property?
jQuery sets param name to “callback” automatically, but it can be overridden. That is similar to each javascript library, so the webpage connecting to the API should always be able to use “callback”. I don’t see any reason why it would need to be configurable as long as we document that “callback” is the name of the callback parameter for JSONP requests.
A hardcoded parameter name might conflict with existing implementations using the plugin. Secondly, if other systems define how the restful webservice is called and you just have to provide an implementation, the hardcoded value might cause problems.
May seem far fetched, but it can happen.
Just that fact that jQuery does it this way doesn’t make it a standard.
other systems dont define how the webservice is called
The webservice defines how it must be called.
You program against us as an api… So yes then we have the doc where we define that callback param must be used for jsonp. Thats our api definition. I agree with Scott about that.
dont know about existing stuff that are using json as return values and use the callback as a parameter (so yes they now get different json back)
So in that case it is more like a boolean (jsonp support or not)
we are bumping to the exact same issue, as Scott started this topic.
Is it save to use his version? without breaking other functionality?
As far as we see, this patch is not applied to the restfull plugin in 5.2.7.
When can we expect, this patch in the version of Servoy itself??