Marc Hadley wrote:
> Proposal take 3 (removed the complex per-resource approach to allow
> simple URI preprocessing):
>
> - We only offer automatic support for content types and language,
> nothing for charset or encoding negotiation.
>
> - The feature is controlled by ApplicationConfig.getMediaTypesMap
> (Map<String, MediaType) and ApplicationConfig.getLanguageMap
> (Map<String, String). If both maps are empty (the default) then the
> feature is disabled.
>
> - When the feature is enabled:
>
> * A request URI is pre-processed to remove extensions that match a key
> in the media types or language maps. The corresponding value of a
> matching key is used to override the accept or accept-language header.
>
> * If a URI template ends in a variable then the variable value is
> injected without the matching extensions.
>
> - Existing UriInfo methods are not affected, all 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,
> * UriInfo.getPlatonicRequestUriBuilder which returns a URI builder for
> the request minus the extensions
> * UriBuilder.extension(String) that adds the supplied extension to the
> current final path segment.
>
> An example:
>
> mediaTypeMap = {"xml"=>"application/xml", "json"=>"application/json"}
> languageMap = {"en"=>"en", "fr"=>"fr"}
>
> @Path("widgets/{id}")
> public class WidgetResource {
> @GET
> String get(@PathParam("id") String id) {
> }
> }
>
> GET /widgets/1 => id=1, accept and accept-language are unaffected
> GET /widgets/1.xml => id=1, accept=application/xml, accept-language is
> unaffected
> GET /widgets/1.json => id=1, accept: application/json, accept-language
> is unaffected
> GET /widgets/1.xml.en => id=1, accept: application/xml, accept-language: en
> GET /widgets/1.foo => id=1.foo, accept and accept-language are unaffected
> GET /widgets/1.foo.xml => id=1.foo, accept=application/xml,
> accept-language is unaffected
> GET /widgets/1.xml.foo => id=1.foo, accept=application/xml,
> accept-language is unaffected
>
> Thoughts, comments ?
The only thing i find a little odd is the last example
GET /widgets/1.xml.foo => id=1.foo,
accept=application/xml, accept-language is unaffected
as it removes the 'xml' from the middle of the last path segment.
Perhaps it would be less strange (but a little more work for us) to
specify the following:
Obtain each extension from the last path segment from right to left and
continue until:
1) an extension is not recognized;
2) both the lang and type are recognized
3) a dup lang or type is recognized
Any recognized extension is then removed from the last path segment.
1) would mean:
GET /widgets/1.xml.foo => id=1.xml.foo,
accept and accept-language are unaffected
2) would mean
GET /widgets/1.fr.json.xml.en => id=1.fr.json,
accept: application/xml, accept-language: en
3) would mean:
GET /widgets/1.xml.json.fr.en => id=1.xml.json.fr,
accept is unaffected, accept-language: en
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109