Markus,
I think we all want to provide tools for people to write better applications, including better support for structural links, if possible. If we didn't, we wouldn't have spent time evaluating your proposal.
So this is not about wanting to support something, as you are trying to put it for some reason, it is about finding a solution that we think is reasonable in terms of what it provides for developers and what it demands from the spec and the implementors. You seemed to suggest you had such a solution, and that's how we got here.
-- Santiago
> On Dec 22, 2014, at 11:29 AM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
> Santiago and Bill,
>
> I think we're completely running in the wrong direction! I never demanded
> that JAX-RS 2.1 must have support for structural links. Actually this
> discussion started by an introduction of mine which clearly said that
> _structural_ links are NOT the most important issue with hypermedia, while
> improved support for _transactional_ links indeed IS. Indeed it was Santiago
> who ASKED for a proposal how such an API COULD look like, basing on the
> manually hard-coded solution we've developed in the past and run in-field
> for years. I never said my proposal is either complete or fully working, but
> CLEARLY said it is just a first hacked _draft_ which COULD serve as a base
> for a solution. It is definitively NOT the final solution itself and won't
> become it if nobody wants such an API or is willing to provide answers to
> the questions you raised.
>
> Instead, I asked TWICE if we actually WANT structural links support, and did
> not get an answer from anybody but Bill so far.
>
> Hence, I will stop here discussing any details on my proposal as it was
> never mentioned as "the" final solution, nor seems to be wanted by "anybody"
> (I wonder why Red Hat, Casey and me ever invested time to provide such
> solutions). If the JSR 370's "hypermedia" charter is to be interpreted as
> "transaction links only" this is fine for me.
>
> I would be happy if JAX-RS 2.1 comes up with a vendor-neutral structural
> links support API, but I can live more years without it. I do not have a
> general solution in my pocket, and I never pretended so. If such an API is
> wanted, I hereby ask the other experts to chime in and find solutions to the
> problems outlined by Santiago and Bill, or to outline their own API proposal
> instead.
>
> It's not only _my_ job to make up my mind about an API and solve all
> problems alone. This is a common effort. Either you help with this, or we
> simply kill the topic right now, as apparently nobody has interest in
> providing a solution.
>
> Merry X-mas,
> -Markus
>
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 22. Dezember 2014 16:22
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: Re: Hypermedia API
>
>
>
> 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
>