> On Dec 21, 2014, at 1:10 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
>>> About the missing metadata can you please elaborate what you think is
>>> missing hence imposes a need to "guess"?
>> The container has to guess how to resolve B in your example because you
>> have not provided the resource class and method name that contains the
>> @Path that resolves B.
>
> Maybe I miss something, but I think it should be fairly straightforward to
> implement "lookupLink" given an instance of class "B" at runtime using a
> dumb brute force algorithm:
>
> * Iterate over all resources
> * For each resource iterate over all resource methods
> * If resource method's return type is "B", add it to candidates list.
> * After that, iterate over all candidates
> * If candidate is "@GET" then return this one as the final result.
> * If no candidate is "@GET" then return the first one as the final result.
> * If there are no candidates, then this application has a programming error,
> because the application vendor wants to link "B" but has no resource method
> for it.
Did you even work out an example for this algorithm? I see several things wrong with it: (1) the fact that a resource method returns a certain type, does not imply is the one you want (2) path variables (3) resource locators, etc.
Example (1):
@Path("/address/{id}")
class AddressR {
@GET
public Address get(@PathVariable("id") String id) { ... }
}
@Path("/person/{id}")
class PersonR {
@GET
public Person get(@PathVariable("id") String id) { ... }
@GET
@Path("address")
public Address getA(@PathVariable("id") String id) { ... }
}
@Path("/company/{id}")
class CompanyR {
@GET
public Company get(@PathVariable("id") String id) { ... }
@GET
@Path("address")
public Address getA(@PathVariable("id") String id) { ... }
}
There are 3 resource methods returning Address, but which one do you choose? It depends. Also, how does the framework fill out the values for {id} in each case when constructing a URI?
This does not even consider the issues related to resource locators whose return types are other resources and not model types.
Is it possible to solve this problem by providing additional meta-data (e.g. annotations)? Perhaps, but I don't know if we want to go that far ...
-- Santiago