I was for it back then and am still for it now.
I'm not sure it should be enabled by default - if so, it should be
very obvious how to disable it.
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/
On Mar 3, 2008, at 5:37 PM, Paul Sandoz wrote:
> Marc Hadley wrote:
>> Any other feedback on this proposal ? When we discussed it
>> originally the EG seemed to be generally in favour of adding this
>> kind of functionality - is that still the case ?
>
> When we discussed initially i was a bit skeptical but then i looked
> more into the issue (reading the RESTful Web services book helped a
> lot) and now think it useful enough that i plan to implement it but
> i would prefer that it be part of JAX-RS.
>
> Paul.
>
>> Marc.
>> On Feb 19, 2008, at 12:46 PM, Marc Hadley wrote:
>>> I'd like to revive a thread started way back in Sept last year,
>>> see: https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=650
>>>
>>> The topic was support for URI-based content negotiation,
>>> essentially allowing a client to
>>>
>>> GET /foo.xml
>>>
>>> as an alternative to
>>>
>>> GET /foo
>>> Accept: application/xml
>>>
>>> I'd like to offer the following concrete proposal:
>>>
>>> - We only offer automatic support for content types, nothing for
>>> language or charset negotiation.
>>>
>>> - When the feature is enabled:
>>>
>>> * A request URI that ends with an extension is matched as if that
>>> extension were not present. E.g. @Path("widgets") would match
>>> requests for widgets, widgets.xml and widgets.json
>>>
>>> * If a URI template ends in a variable then the variable value is
>>> injected without the extension. E.g. @Path("widgets/{id}") with
>>> request for widgets/1.xml and @PathParam("id") String id would
>>> result in a value of "1" for id.
>>>
>>> * The extension is compared to the keys in
>>> ApplicationConfig.getExtensionMappings (Map<String, MediaType). If
>>> a match is found any Accept header value is replaced with the
>>> value for the matching key.
>>>
>>> - An @Path property style is provided to control the behavior. A
>>> value of 'platonic' means that the path should be treated as part
>>> of a platonic URI and the above behaviour is enabled. A value of
>>> 'distinct' means that the path is distinct and disables the above
>>> behaviour. The default value of 'default' defers to an application
>>> wide default specified as a property of ApplicationConfig (this
>>> will default to not enabled).
>>>
>>> - Existing UriInfo methods are not affected, any extension in the
>>> URI is included in the path returned by any of the methods. For
>>> convenience we add UriInfo.getPathExtension() that returns the
>>> extension or null if there isn't one, and
>>> UriInfo.getPlatonicRequestUriBuilder which returns a URI builder
>>> for the request minus the extension. We also add a
>>> UriBuilder.extension(String) that adds the supplied extension to
>>> the current final path segment.
>>>
>>> An example:
>>>
>>> @Path("widgets")
>>> public class WidgetsResource {
>>>
>>> @Context UriInfo uris;
>>>
>>> @GET
>>> @ProduceMime({"application/xml", "application/json")
>>> public WidgetList getWidgets() {
>>> ....
>>> }
>>>
>>> @POST
>>> @ProduceMime({"application/xml", "application/json"})
>>> public Response addWidget(Widget input) {
>>> Widget w = createWidgetEntry(input);
>>> URI platonic = uris.getBaseUriBuilder()
>>> .path(WidgetResource.class)
>>> .build(w.getId());
>>> URI distinct = uris.getBaseUriBuilder()
>>> .path(WidgetResource.class)
>>> .extension(uris.getExtension())
>>> .build(w.getId());
>>> return Response.created(platonic)
>>> .contentLocation(distinct);
>>> }
>>> }
>>>
>>> @Path("widgets/{id}")
>>> public class WidgetResource {
>>> ...
>>> }
>>>
>>> Assume you have an app config that maps "xml" to application/xml
>>> and "json" to application/json. Also assume you have the required
>>> msg body readers and writers for XML and JSON.
>>>
>>> GET /widgets.xml will get you XML, GET /widgets.json will get you
>>> JSON, GET /widgets will get whichever matches your accept header
>>> most closely.
>>>
>>> You can POST XML or JSON to /widgets.xml but you'll always get
>>> back XML. Same for /widgets.json but you'll always get back JSON.
>>>
>>> If you POST to a distinct URI you'll get a platonic location and a
>>> distinct content location. If you post to a platonic you'll get
>>> platonic location and content location (the latter is unfortunate
>>> but a custom message body writer could patch the value once the
>>> format is known.
>>>
>>> Thoughts, comments ?
>>> Marc.
>>>
>>> ---
>>> Marc Hadley <marc.hadley at sun.com>
>>> CTO Office, Sun Microsystems.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>