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
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/>
>>
>>
>>
>