Hello Marc,
the idea is in both cases below also the usseability from a browser,
where you need a lot of clicks to change the prefered language for one
call, and back for another call. Change the preferences for the media
type is not possible in the most browsers, I think.
>> What about a MultivaluedMap for getMediaTypes()? This could be useful
>> for XML,(*.xml -> { text/xml, application/xml, application/*+xml
>> }Javascript (*.js -> { text/javascript, application/javascript}) and
>> perhaps others.
> I don't think I understand the reason for a one-to-many config. If
> .xml mapped to multiple types then you'd have to fall back to the
> original accept header to select which one to use. But if you are
> going to use the original accept header then why bother with the
> extension at all, you can just use the accept header with the platonic
> URI...
You are right, you could solve it without the one-to-many-config. The
idea is: An developer could build a generally useable mapping, which he
uses everywhere. Than he can use it and it don't care if he wrote
@ProduceMime("text/xml") or @ProduceMime("application/xml") or
@ProduceMime({"text/xml", "application/xml"}) with the same media type
mapping.
>>> * Each extension is compared to the keys in
>>> ApplicationConfig.getMediaTypesMap (Map<String, MediaType) and
>>> ApplicationConfig.getLanguageMap (Map<String, String). If a match is
>>> found the corresponding Accept or Accept-Language header value is
>>> replaced with the value for the matching key.
>> Should JAX-RS support /widgets/5.xml.en.json.fr -> Uri = /widgets/5,
>> Accept: text/xml,application/json and Accept-Language: en, fr. ?
>> If yes, it should be defined, if en or fr has the higher quality; the
>> same for xml and json. I propose, the first extension has a higher
>> quality than the laters.
> I had naively thought that the final .json.fr would overwrite the
> prior .xml.en. IMO use of extensions is about selecting a single
> distinct representation, not multiple possibilities.
The idea is the following: A (human) user want to download a document.
He prefers his own language (e.g.: "de"), but english or frensh is also
ok. Because he also want to print it, he preferes PDF, but OpenOffice or
Word is also good; if not available, he want the document in HTML.
Then he type
"
http://examle.com/path/document.de.en.fr.pdf.odt.rtf.doc.html" in his
browsers address line. That's very flexible for the user, and he must
not check a lot of links.
It's rigth, that we reinvent the flexible HTTP content negotiation
mechanism with a new mechanism here. But on the other hand we offer
another way, which is easy useable in a browser.
best regards
Stephan