Marc Hadley wrote:
>>
>> Multiple possible methods / root resource classes for one request
>> in the algorithm for matching requests to resource methods, part 1e
>> does not define what happens, when multiple root resource classes have
>> the same @Path annotation. The same is in part 2 f/g and 3b/c. Is it
>> implementation dependent, like the choose of the constructor, if there
>> are more valid constructors (all parameters correct annotated and with
>> the same no of parameters?) Or must the implementation generates error
>> status 500?
>> BTW: To the illustrated case you can say, that the developer should be
>> more intelligent, but another tricky case with the same problem are
>> two classes or methods annotated with @Path("abc/{var}") and
>> @Path("{var}/def") called with URI "http://.../.../abc/def"
>>
Ouch! well caught. Hmmm... do we require a better ordering function? if
the number of explicit characters is equal then the one with the most
occurring sooner is ordered first? It would be nice to come up with a
simple cost function rather than a bunch of if/else rules and resorting
to analyzing path segments.
Perhaps an alternative is for the application to specify how to resolve
when the runtime cannot?
> You raise a tricky issue, it seems to me that generating an error would
> be the right thing to do. Unless someone has a better idea for how to
> pick amongst the alternatives ?
>
A more complicated approach is to consider the case of being able to
match against multiple root resources. For example, consider the case of
two root resources, r1 and r2, where r1 takes precedence r1 over r2 (r1
was class loaded before r2, so the precedence is arbitrary). A request
matches the @Path of r1 but the runtime fails to find a match to invoke
a HTTP method. The runtime could then try and match against r2.
There are a definite sub-set of patterns that are validation errors, for
example, two HTTP methods with the same path, method and
producing/consuming the same media (we should enumerate them). But in
principle the same logic for managing multiple root resources could be
applied to sub-resource locators.
Currently the matching algorithm traverses just one path through the
'path' tree specified by the set of resources. No backtracking is
performed. Arguably it could complicate both the implementation
(although it is certainly possible to do) and the application
development if backtracking were allowed.
I can see a use-case for root resources where by one could add an
additional root resource with the same path supporting different media
types because one did not want to modify the code of the existing
resource. It may sound like a cool thing to do but i am really not sure
if this is really useful.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109