Ryan McDonough wrote:
> 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.
>
Right.
> 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.
>
It is sort of swings and roundabouts: the URIs are augmented and changes
conneg, or conneg is changed and augments the URIs. IMHO URIs are the
most important thing thus it is best to be explicit about such changes
on the artifacts we use to express URIs.
One issue with placing such information on the produce is the matching
algorithm does not have consistent access to such information. For
example, when using a sub-locator method the runtime does not know what
resource class will be returned, and therefore what HTTP methods are
present, until a sub-locator method has been matched, invoked and has
returned a resource class. So, if possible, we still need to associate
the information with the URI template such that the set of regular
expressions can be produced.
> Ryan-
>
> p.s.
> It's been a very LONG day just in case I'm not making much sense :)
>
You made sense :-)
Paul.
>
> On 9/26/07, *Marc Hadley* < Marc.Hadley_at_sun.com
> <mailto: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 <http://sun.com>>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
>
>
>
>
> --
> Ryan J. McDonough
> http://www.damnhandy.com
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109