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