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.
> @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
> 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
>
>
> 2011. 7. 5. 오후 12:40에 "Bill Burke" <bburke_at_redhat.com>님이 작성:
>
> Hypermedia is entity body driven, so, other than Link header support, I don't see what we can be done in regards to a specification. XML/JAXB is the only standardized media type JCP has dealt with and I'm very doubtful meaningful integration can be done with it considering JAXB's limitations.
>
>
> On 7/1/11 1:47 PM, Santiago Pericas-Geertsen wrote:
> >
> > Hello Experts,
> >
> > Even though we are stil...
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>