Hello Marc,
that's a good proposal. I put some remarks between the points, see below:
> - We only offer automatic support for content types and language,
> nothing for charset or encoding negotiation.
>
> - The feature is controlled by a combination of annotation and config:
> * A property of ApplicationConfig defines the default
> (enabled/disabled).
I think it is enough if getMediaTypes() and getLanguages() both return
null or an empty map. 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.
> [...]
>
> * 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.
> - Existing UriInfo methods are not affected, any extensions in the URI
> are included in the path returned by any of the methods. For
> convenience we add:
>
> * UriInfo.getPathExtension() that returns the extensions as a String
> or null if there isn't one,
Define if with a "." at the beginning or without?
> [...]
>
> Issues:
>
> (i) Because matching is controlled on a per-resource basis we can't
> just preprocess the request URI and then use that for matching. It
> would be simpler but less flexible without the per-resource control.
> Is that a tradeoff folks would consider ?
I think: pre-process and then match, or fully disabled for the full
JAX-RS environment instance. If someone needs the file name with
extension (for returning a file from the filesystem or whatever) he
could use UriInfo.getPath() or UriInfo.getPathSegments(). It is useful
to add UriInfo.getLastPathSegment() ?
> (ii) A result of (i) is that for efficiency we essentially treat a URI
> with any extensions as matching a platonic URI. E.g.
> widgets.foo.bar.fr.xml would match WidgetsResource above and be
> treated the same as widgets.fr.xml or widgets.xml.fr. Rejecting URIs
> with extensions that don't match one of the configured extensions on a
> per-resource basis would be expensive, rejecting them globally would
> mean you couldn't have a distinct resource path that had a
> non-conforming extension.
Yes, we should keep in mind, that this forbid all "." in the URI, if
this feature is enabled. For implementing I would look for the last
point in the String, get the extension and shortening the URI, and loop,
until a non-matching is found. I think, this is an efficient way.
Perhaps we should only forbid extensions in @Path given this
getMediaTypes() and getLanguages(), when reading it the first time, or
warn in a log.
regards
Stephan