Thank you for coming up with this proposal, which seems as a good starting
point for the discussion but looks a bit complex to the average user. I
want to propose the following "defaults", which helps a lot people and is
less complex than supplying all that parameters:
@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".
@Ref.style -- Typically in the web resources are virtually always
relatively addressed (ever wrote <http://> 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.
@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.
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… :-)
@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. If there are more
conditions, I would be more happy with a Java API than a String based
syntax. In our application we solved this by the general invention of a
"Constraint" interface (which is not HATEOAS dependend, but more general
like java.lang or java.util things are). This would not only run faster,
but also allows to syntax-check for typos (which always is hard to find).
@Binding -- I would prefer not using String syntax here, too, due to the
same reasons.
@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.
Regards
Markus
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 <http://bill.burkecentral.com/>