Paul and I discussed this at length this morning and I'm going to try
to rewrite the algorithm along the lines you suggest. The rewrite
won't actually affect the algorithms results but will hopefully be
clearer. Its worth pointing out that implementations aren't required
to implement resource matching using the algorithm as described,
rather they are required to produce results that are the same - I'll
add an explicit note of this to the specification.
Marc.
On May 15, 2008, at 5:54 AM, Sergey Beryozkin wrote:
> > Bullet 2 is checking to see whether the current object consumes the
> > remainder of the request URI (2.a), whether it contains sub-resource
> > methods that consume the remainder of the request URI (2.h),
>
> Well, the above says to me that a bullet 2 is also, at least
> partially, about selecting the methods.
>
> Ex :
>
> @Path("/")
> class Bar {
>
> @ProduceMime("application/xml")
> @Path("{id}") @GET getXml() {}
>
> @ProduceMime("application/json")
> @Path("{id}") @GET getJson() {}
>
>
> @Path("{id}") @PUT put() {}
>
> }
>
> As it currently stands bullet 2 will just identify Bar as being the
> legitimate holder of methods which can be invoked.
> In bullet 3 then we again need to check both methods, this time for
> the match against @GET or @PUT. As I suggested earlier, if 2.d were
> updated something like this :
>
> • Remove members derived from Tmethod (those added in step 2(c)i)
> for which the final capturing group value is neither empty nor ‘/’
> *or when Tmethod has a method designator which does not match the
> current Http request method*
>
> then at least it would only be getXml()/getJson pair or put() which
> would make it to the bullet 3.
>
> Then the bullet 3 would only talk about Produce/ConsumeMimes, as the
> Http method match has already been done and UriTemplate match has
> already been done too earlier in bullet 2.
>
> Overall though, the algorithm's formal picture gets much clearer to
> me, thanks.
>
> About (.+)?. Would it make any sense to have an additional property
> added to @Path such that if it's set would give a hint whether (.+)?
> or the current (.*)? should be used ?
>
> For example, default can be (.+)? but with
> @Path(value="foo{bar}",optional=true) it will be (.*?)
>
> or the other way around...
>
>
> Cheers, Sergey
>
> >
> > Marc.
> > ---
> > Marc Hadley <marc.hadley at sun.com>
> > CTO Office, Sun Microsystems.
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> > For additional commands, e-mail: users-help_at_jsr311.dev.java.net
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.