Bill Burke wrote:
>>> I just don't see what the big deal is of supporting multiple
>>> resources/different media types, same path.
>>>
>> I guess it just makes the matching algorithm a bit more complex.
>>
>
> Depends on how you implement it I guess...
>
Does your implementation support sub-locators? I am guessing that answer
is a no, from having a quick look at the code you sent for Registry and
Registry.Node class.
One concern i have is two district places can be independently changed
and may cause unexpected results. For example, one developer has written
a library that contains a root resource class that supports some media
type(s). Another developer wants to reuse this library, but they create
their own root resource with the same @Path as a root resource in the
library to support other media types (and further HTTP methods,
sub-methods or other sub-locators). Then the library is updated and it
results in errors in their other code. The only relationship between the
code that is failing is that they share the same @Path.
I am inclined to think that if we choose to support this functionality
we should do so by class inheritance where the extended class has
exactly the same @Path annotation on the super class.
@Path("foo")
class Resource {
}
@Path("foo")
class ExtendedResource extends Resource {
}
The runtime only recognizes one root resource ExtendedResource.
It may not be ideal in terms of swapping in/out functionality for sets
of media types but it gives a much more explicit and controlled contract
while still retaining some modularity of implementation.
Still i am concerned that problems can occur for those writing root
resources for which there was no intention of being extended by others
(namely the original developers forget to put the 'final' modifier on
the class).
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109