format parameter to determine content type?

[Mike Hugo]

Hello,
Is it possible to specify the response format by using a format
parameter? For instance,

http://myurl.com/api/serviceName?format=json
OR
http://myurl.com/api/serviceName?format=xml

?

Thanks for all the work on the plugin, we're starting to use it to
expose some web services and things are going very nicely.

Mike

[Martin Krasser]

Hi Mike,

Am 24.03.11 21:11, schrieb Mike Hugo:

> Hello,
> Is it possible to specify the response format by using a format
> parameter? For instance,
>
> http://myurl.com/api/serviceName?format=json
> OR
> http://myurl.com/api/serviceName?format=xml
>

In general, yes: you have access to the request parameter in resource
classes via the JAX-RS @Context. This allows you to create a response
(using the JAX-RS ResponseBuilder) with the response media type defined
in the URL. This media type is then used by the JAX-RS runtime to either
choose a default message body writer or a custom message body writer.

For Grails domain objects: not supported out of the box. Here, you'll
need to set the response media type in the resource methods using the
ResponseBuilder.type() method, as described above. Shouldn't be a big
deal to change resources classes (generated via 'grails
generate-resources') to use the format parameter instead - but I didn't
try that.

Does that help?

I'm curious: what speaks against using the Accept request header for
content negotiation?. I'm thinking about to support that out-of-the box
for domain objects if there's a good reason for not using the Accept header.

> ?
>
> Thanks for all the work on the plugin, we're starting to use it to
> expose some web services and things are going very nicely.

You're most welcome.

Cheers,
Martin

> Mike

--
Martin Krasser

blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

[Mike Hugo]

Martin,

Thanks for the input, I'll give it a shot.

The reason we'd like to do this is to maintain consistency with some other services that use Grails built in content negotiation, which allows for three mechanisms for determining the format:

http://grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.8 Content Negotiation

- via the accept header

- via a 'format' request parameter

- via a 'file extension', e.g. resource.json or resource.xml

Thanks!

Mike

[ebakke]

Following Mike's thought a little further with respect to 'file/URI
extension' content negotiation...

With Jersey it's easy enough to create my own class that extends
PackagesResourceConfig and to override getMediaTypeMappings().
However, I don't see any way I can register this new class inside with
plugin. If I was using Jersey directly, I'd add a new init-param
inside web.xml. After poking around in the plugin source for a bit,
it looks like something similar to what I'm looking for is being done
for the extra provider paths within the init() method of
JerseyServlet.java. An init param (in this case, with name
com.sun.jersey.config.property.packages) is added with whatever value
resides in Config. I've confirmed that I get the expected results if
I manually add:
config.getInitParameters().put("com.sun.jersey.config.property.resourceConfigClass",
[my_class_name]);

Is there currently any way for me to set more init parameters than
just com.sun.jersey.config.property.packages? Or am I barking up the
wrong tree, and is there a different/better way to go about solving
this problem?

Thanks,
Erik

On Mar 25, 9:11 am, Mike Hugo <m...@piragua.com> wrote:
> Martin,
> Thanks for the input, I'll give it a shot.
>
> The reason we'd like to do this is to maintain consistency with some other
> services that use Grails built in content negotiation, which allows for
> three mechanisms for determining the format:
>
> http://grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.8Content
> Negotiation
> - via the accept header
> - via a 'format' request parameter
> - via a 'file extension', e.g. resource.json or resource.xml
>
> Thanks!
>
> Mike
>

[Martin Krasser]

Hi Erik,

Thanks for sharing your ideas. Setting init parameters for Jersey is
definitely something useful. I created a ticket for it:
http://code.google.com/p/grails-jaxrs/issues/detail?id=38. I'm thinking
about a map of init parameters that can be defined in Config.groovy. We
could even use the same mechanism to set init parameters for the
RestletServlet as well.

Cheers,
Martin

Am 01.04.11 04:08, schrieb ebakke:

[Martin Krasser]

Hi Erik,

I just pushed support for
http://code.google.com/p/grails-jaxrs/wiki/AdvancedFeatures?ts=1301645620&updated=AdvancedFeatures#Init_parameters
to master
(https://github.com/krasserm/grails-jaxrs/commit/21ce038845772c55580fd1234f304342993fc553).
Please let me know if this fits your needs.

For testing, you'll need to checkout the sources and build the plugin
yourself as described in
http://code.google.com/p/grails-jaxrs/wiki/InstallationInstructions.

Cheers,
Martin

Am 01.04.11 08:15, schrieb Martin Krasser:

[ebakke]

Martin,

Fantastic! I'll try it out today. Thanks so much for the quick reply
and the new additions!

Regards,
Erik

On Apr 1, 4:17 am, Martin Krasser <krass...@googlemail.com> wrote:
> Hi Erik,
>

> I just pushed support forhttp://code.google.com/p/grails-jaxrs/wiki/AdvancedFeatures?ts=130164...
> to master
> (https://github.com/krasserm/grails-jaxrs/commit/21ce038845772c55580fd...).

> Please let me know if this fits your needs.
>
> For testing, you'll need to checkout the sources and build the plugin

> yourself as described inhttp://code.google.com/p/grails-jaxrs/wiki/InstallationInstructions.

> >> config.getInitParameters().put("com.sun.jersey.config.property.resourceConf igClass",

>
> >> [my_class_name]);
>
> >> Is there currently any way for me to set more init parameters than
> >> just com.sun.jersey.config.property.packages?  Or am I barking up the
> >> wrong tree, and is there a different/better way to go about solving
> >> this problem?
>
> >> Thanks,
> >> Erik
>
> >> On Mar 25, 9:11 am, Mike Hugo<m...@piragua.com>  wrote:
> >>> Martin,
> >>> Thanks for the input, I'll give it a shot.
>
> >>> The reason we'd like to do this is to maintain consistency with some
> >>> other
> >>> services that use Grails built in content negotiation, which allows for
> >>> three mechanisms for determining the format:
>

> >>>http://grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.8Con...

[ebakke]

Martin,

Works great! Many, many thanks!

Erik

[Martin Krasser]

Glad that I could help.

Cheers,
Martin