Re: JSR311: selectVariant not very useful
+1
Bill Burke schrieb:
> 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.