I'm wondering if this logic could be tied to some of the content negotiation
topics that we have been discussing in other threads? Fundamentally, the
function of platonic URIs is another form of content negotiation but
initiated by the URIs extension rather than the accept header. You could
even go as far as saying it can override the accept header values if needed.
While I'm all for the idea, I'm curious if we are potentially creating
another logic path to do the same thing? I know it's a big change, but it
may be worth considering a way to tie the extension to the @ProduceMime
annotation. Yes it could get ugly, but it will keep things consistent for
both types of negotiation mechanisms. For example it could be that we have:
@UriTemplate(value="{id}")
@HttpMethod
@ProduceMime(variants={_at_Variant("application/xml;q=0.7","xml"),
@Variant("application/json;q=0.9","json")})
SomeItem getItem(@UriParam("id") String itemId) {
This way if the caller requests the URI with an extension or not, the caller
will experience identical behavior if the request a type that is not
supported. My concerns is that we have two mechanisms which perform pretty
similar activities but are configured, we'll have problems with consistency.
Ryan-
p.s.
It's been a very LONG day just in case I'm not making much sense :)
On 9/26/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> On Sep 25, 2007, at 7:05 AM, Paul Sandoz wrote:
> >
> > I don't think it makes sense to support:
> >
> > /collection.xml/1
> > /collection.xml/1.xml
> >
> > The suffices only makes sense on last path segment of the URI.
> >
> The use of sub-resource methods will make this quite complex and
> possibly counter-intuitive. Would it make sense to match the URIs
> above but to simply ignore the extensions on the path segments
> matched to the parent class. E.g.
>
> @UriTemplate(value="collection" extensions=true)
> public class SomeResource {
>
> @HttpMethod
> SomeCollection getAll(@UriExtensions String exts[]) {
> ...
> }
>
> @UriTemplate(value="{id}" extensions=true)
> @HttpMethod
> SomeItem getItem(@UriParam("id") String itemId, @UriExtensions
> String exts[]) {
> ...
> }
> }
>
> With the above you want both
>
> GET /collection.xml, and
> GET /collection/1.xml
>
> to work so it could be tricky to disallow GET /collection.xml/1.xml
> since the URI to resource class matching algorithm first has to match
> the SomeResource class before it can match the getItem method.
>
> 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
>
>
--
Ryan J. McDonough
http://www.damnhandy.com