On Mar 3, 2008, at 4:14 PM, Larry Cable wrote:
> I am naively assuming that retrofitting language would be a PITA ...
>
IIRC, its a PITA regardless ;-).
Marc.
>
> From: Marc Hadley
> Sent: Mon 3/3/2008 1:09 PM
> To: dev_at_jsr311.dev.java.net
> Subject: Re: JSR311: URI-based conneg
>
> On Mar 3, 2008, at 2:15 PM, Larry Cable wrote:
>
> > now is the time to do this; retrofitting this sort of behavior in
> > later releases is likely to be painful and not
> > likely to be backwards compatible
> >
> Did you mean:
>
> (a) Now is the time to do URI-based conneg (as proposed, media type
> only), or
> (b) Now is the time to do URI-based conneg including language.
>
> Thanks,
> Marc.
>
> > From: Stephan Koops
> > Sent: Mon 3/3/2008 11:07 AM
> > To: dev_at_jsr311.dev.java.net
> > Subject: Re: JSR311: URI-based conneg
> >
> > Why not support languages, for example: GET /foo.en.xml ? I think,
> > it is
> > very useful to be used by browsers.
> > I tried to look in the mailing list archive, but it didn't answer.
> >
> > Stephan
> >
> > Marc Hadley schrieb:
> > > 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 ?
> > >
> > > 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.
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >
> >
> > Notice: This email message, together with any attachments, may
> > contain information of BEA Systems, Inc., its subsidiaries and
> > affiliated entities, that may be confidential, proprietary,
> > copyrighted and/or legally privileged, and is intended solely for
> > the use of the individual or entity named in this message. If you
> > are not the intended recipient, and have received this message in
> > error, please immediately return this by email and then delete it.
>
> ---
> 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
>
>
> Notice: This email message, together with any attachments, may
> contain information of BEA Systems, Inc., its subsidiaries and
> affiliated entities, that may be confidential, proprietary,
> copyrighted and/or legally privileged, and is intended solely for
> the use of the individual or entity named in this message. If you
> are not the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.