On 07/08/2011 06:24 PM, Sergey Beryozkin wrote:
> Santiago Pericas-Geertsen wrote:
>> Markus,
>>
>> Thanks for the feedback. Please note that there are a few defaults that
>> I didn't use or talk about in the write-up in order to show all the
>> steps. I'm also not the original designer of this API so I don't know
>> the rationale of all the decisions made. See inline.
>>
>>> @Ref.resource -- It should be possible to omit this, and instead
>>> declare *once* the sole resource used for resolving this reference.
>>> That means, rather than always giving the resource here, I instead
>>> would prefer to mark one resource as the "main resolver" for
>>> references of this type in *all* @Refs. Reason: An apple is an apple
>>> and will not become a peach at some particular link. So it makes no
>>> sense to enforce repeating of the apple resolver. In our already
>>> shipping application we solved this using a registry that maps
>>> resources on reference types, but obviously it is much smarter to just
>>> mark a resource using an annotation as "the apple resolver".
>>
>> I see your point. Let me think about this a bit more.
>>
>>> @Ref.style -- Typically in the web resources are virtually always
>>> relatively addressed (ever wrote http:// into <img src>?), so the
>>> default should be RELATIVE. Also I think it is not dependend of the
>>> particular link but should be a global setting. That means, I want to
>>> omit this parameter and instead tell the resource "whenever you need
>>> to resolve @Ref, then please use RELATIVE links". This reduces a lot
>>> of clutter. If anybody would ever want ABSOLUTE style I assume he
>>> wants it for anything the resource does, not just for one particular link.
>>
>> Default is ABSOLUTE in Jersey. Wouldn't it be simpler for Client APIs
>> if URI's were absolute? I'm thinking about hypermedia clients too.
>>
>
> It appears ABSOLUTE are considered more portable. Ex, not all clients
> are capable of keeping the base or interpreting xml:base in case of XML
> responses, etc
>
+1 Marek
> Sergey
>
>>> @Ref.bindings -- In our already shipping application we are not using
>>> implicit bindings, i. e. we expect (unless otherwise specified) that
>>> the parameter names are matching the JAXB's property names. It would
>>> reduce a lot of clutter if we could agree upon such a fallback, so
>>> people only need to give the bindings parameter in case of differing
>>> names.
>>
>> Seems reasonable. Are you suggesting that "foo" in a URI template
>> "...{foo}..." be defaulted to "{instance.foo}"? Where "instance" refers
>> to the representation instance.
>>
>>> Using this defaults it would be possible to enable HATEOAS with just
>>> an unparameterized @Ref written into the JAXB document. This is how we
>>> implemented it in our current app, and we would be not very happy to
>>> get a more flexible but more cluttering standard… :-)
>>
>> Right.
>>
>>> @Ref.condition -- Interesting idea, but the question is, whether
>>> there will be any other conditions besides "is null"? If not, we can
>>> omit that, since null will not get rendered by a JAXB marshaller anyways.
>>
>> This condition can be used even if there's no reference, e.g., in a
>> Link header declaration. If we force developers to use URI variables,
>> regardless of whether these are rendered inline or as link headers, then
>> we should revisit this. A suitable default could be defined too.
>>
>>> @Binding -- I would prefer not using String syntax here, too, due to
>>> the same reasons.
>>
>> You mean EL expressions? EL expressions are used in many other places
>> in the EE world.
>>
>>> @Link -- Actually this looks scary. If I want to make the JAXB
>>> marshaller render LINK headers instead of XML URLs, it should be
>>> sufficient to configure that in one line instead of that huge code
>>> block. Something like a boolean parameter set at the marshaller or
>>> like that. I do not think that it should be part of the representation
>>> class itself, but more a general rendering configuration.
>>
>> Yes, I tend to agree. You're suggestion is to always use URI (or Link
>> ;) variables in the representation and declare the type of rendering
>> desired externally. Correct?
>>
>> -- Santiago
>>
>>>
>>> *From:* Santiago Pericas-Geertsen
>>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
>>> *Sent:* Mittwoch, 6. Juli 2011 21:09
>>> *To:* jsr339-experts_at_jax-rs-spec.java.net
>>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
>>> *Subject:* [jsr339-experts] Re: Hypermedia Proposals
>>>
>>> Hi All,
>>>
>>> I've updated the wiki [1] to describe the type of declarative
>>> hyperlinking supported in Jersey using @Ref and @Link. Declarative
>>> hyperlinking in Jersey supports both links in representations and link
>>> headers.
>>>
>>> Hyperlinking is a first step, but HATEOAS is more than that. I've
>>> also added some links to related work towards the end of the page.
>>> Please feel free to include other links there.
>>>
>>> Guilherme: I came across [2]. Is this the latest on your research in
>>> this area?
>>>
>>> -- Santiago
>>>
>>> [1] http://java.net/projects/jax-rs-spec/pages/Hypermedia
>>> [2] https://github.com/caelum/restfulie-java/wiki/java_hypermedia
>>>
>>> On Jul 5, 2011, at 12:47 PM, Guilherme Silveira wrote:
>>>
>>>
>>> Cant we support link headers? Would already incentivate people doing
>>> rest... Even if limited to links.
>>>
>>> Cant we also incentivate response based links and forms as in
>>>
>>> Response.getLinksFor(myEntity)
>>>
>>> An http api withou hypermedia is, in the best case, an http api - not
>>> a rest one.
>>>
>>> Regards
>>>
>>> Guilherme Silveira
>>>
>>>
>>> > Hello Experts,
>>> >
>>> > Even though we are stil...
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>>
>>>
>>>
>>
>