On 12/22/2014 10:01 AM, Santiago Pericas-Geertsen wrote:
>
>> On Dec 21, 2014, at 1:10 PM, Markus KARG <markus_at_headcrashing.eu
>> <mailto: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 ...
>
I see we are thinking the same Santiago. This is the problem I've had
so far with any annotation-driven hypermedia extension (even our own).
* How do you resolve the resource method to fill the link?
* How do you fill in the path, query, and matrix params of the link?
* How do you decide the title and rel of the link?
* How do you deal with standard and custom link types? "self", "edit",
"delete", "update", etc...
IMO, too much magic here, IMO, it would just be simpler to do it manually.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com