JSONP interceptors

[Josh Holtzman <jh...@berkeley.edu>]

With some help from sergeyb and dkulp yesterday, I wrote some very simple
CXF interceptors that enable transparent JSONP capabilities in JAX-RS.  If a
request contains a "jsonp" parameter in the querystring, and the response's
content type is "application/json", the response is wrapped in the callback
specified by the jsonp parameter.

For example, a response from a hypothetical JAX-RS endpoint at /foo.json
looks like this:

{"foo":"bar"}

The response to the same URL with a jsonp parameter
(/foo.json?jsonp=handleCallback) would look like this:

handleCallback({"foo":"bar"})

With jsonp, the /foo.json service can be called from 3rd party browser-based
mashups.  Without it, browsers' same-origin policy limits the usefulness of
the endpoint.  If there is interest in including this functionality in CXF
itself, I'd be happy to submit a patch.

Thanks,
Josh

Re: JSONP interceptors

[Sergey Beryozkin <sb...@gmail.com>]

Hi Josh

On Sun, Aug 29, 2010 at 3:12 AM, Josh Holtzman <jh...@berkeley.edu>wrote:

> With some help from sergeyb and dkulp yesterday, I wrote some very simple
> CXF interceptors that enable transparent JSONP capabilities in JAX-RS.  If
> a
> request contains a "jsonp" parameter in the querystring, and the response's
> content type is "application/json", the response is wrapped in the callback
> specified by the jsonp parameter.
>
> For example, a response from a hypothetical JAX-RS endpoint at /foo.json
> looks like this:
>
> {"foo":"bar"}
>
> The response to the same URL with a jsonp parameter
> (/foo.json?jsonp=handleCallback) would look like this:
>
> handleCallback({"foo":"bar"})
>
> With jsonp, the /foo.json service can be called from 3rd party
> browser-based
> mashups.  Without it, browsers' same-origin policy limits the usefulness of
> the endpoint.  If there is interest in including this functionality in CXF
> itself, I'd be happy to submit a patch.
>
> Sounds good - please do :-).
One thing is that the policy which has been followed so far by the JAXRS
module is that query parameters which are meant for the runtime
interceptors/filters are prepended with "_". If you prefer just "jsonp" as
opposed to "_jsonp" then it's fine, but I;d be nice if _jsonp was also
supported, just so that users could do say
/foo?_type=json&_jsonp=handleCallback, where /foo?_type=json is equivalent
to /foo.json

thanks, Sergey


> Thanks,
> Josh
>

Re: JSONP interceptors

[John Fuhr <ej...@gmail.com>]

try it and let's take a look at the limits of "same-origin policy" as well
as the limits of integration with a full-fledged part of a WSDL message...

john fuhr



On Sat, Aug 28, 2010 at 9:12 PM, Josh Holtzman <jh...@berkeley.edu>wrote:

> With some help from sergeyb and dkulp yesterday, I wrote some very simple
> CXF interceptors that enable transparent JSONP capabilities in JAX-RS.  If
> a
> request contains a "jsonp" parameter in the querystring, and the response's
> content type is "application/json", the response is wrapped in the callback
> specified by the jsonp parameter.
>
> For example, a response from a hypothetical JAX-RS endpoint at /foo.json
> looks like this:
>
> {"foo":"bar"}
>
> The response to the same URL with a jsonp parameter
> (/foo.json?jsonp=handleCallback) would look like this:
>
> handleCallback({"foo":"bar"})
>
> With jsonp, the /foo.json service can be called from 3rd party
> browser-based
> mashups.  Without it, browsers' same-origin policy limits the usefulness of
> the endpoint.  If there is interest in including this functionality in CXF
> itself, I'd be happy to submit a patch.
>
> Thanks,
> Josh
>