This was issue 1:
https://jsr311.dev.java.net/issues/show_bug.cgi?id=1
You can read the discussion starting at:
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=422
I think the Variant stuff is useful if you only have certain
combinations of media type, language and encoding available. IIRC, we
decided against addition annotations due to the combinatorial
explosion problem with resource methods if you don't support all media
types in all languages and all encodings.
Marc.
On Jul 30, 2009, at 1:07 PM, Bill Burke wrote:
> I hope you don't mind me telling you how ugly the selectVariant API
> is. I really can't seem myself ever using it, why?
>
> * Content-encoding, in general, is not something you can do with JAX-
> RS apis unless you want to do your own streaming.
>
> * Content encoding is something you do, or not do and is completely
> orthogonal to the media type and language.
>
> * 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.
>
> * 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
>