On Jul 30, 2009, at 1:07 PM, Bill Burke wrote:
>
> * I can't, in practice, ever see the use case where a resource
> method would support a language for one media type, and not another,
> at least where a JAX-RS service is concerned.
>
I can see the case where a resource method might support one language
for some URI template value and another language for another. Same
goes for media type. The API supports more dynamic conneg than static
annotations could.
Marc
> * In most JAX-RS services, the response media-type is automatically
> chosen based on return type, @Produces, and accept-header.
>
> That being said, I think it would be more useful to add a
> @ProduceLanguages annotation and a @AcceptLanguage annotation
> instead. A lot less code. For example:
>
> @Produces({"application/xml", "application/json"})
> @ProduceLanguages({"en", "es"})
> @GET
> public Customer getCustomer(@AcceptLanguage Locale language) {
> ...
> }
>
> This is a lot simpler, less code, and easier to explain than:
>
>
> @Produces({"application/xml", "application/json"})
> @GET
> public Customer getCustomer(@Context Request request) {
> Variant.VariantBuilder vb = Variant.VariantBuilder.newInstance();
> vb.languages(new Locale(“en”), new Locale(“es”));
> Variant v = request.selectVariant(vb.build());
> Locale language = v.getLanguage();
> ...
>
> }
>
> Even just using HttpHeaders.getAcceptableLanguages() is better if
> you didn't want to add the additional dispatching logic and
> annotations.
>
> I strongly suggest we deprecate the Variant API and prune it in a
> later versions of the specification.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>