Same point of view on Annotation based link generation: annotations
are (way too) limited and usually imply in using yet another language
for describing "cases".
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
2011/7/7 Markus KARG <markus_at_headcrashing.eu>:
> 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:// 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
>
>
>
>