Hi Santiago,
Thanks for the feedback.
> 2. Serializing links in the controller
>
https://github.com/caelum/jaxrs2-caelum/commit/9ba9179e9f2dce71e0a36c8e7c7ab857579ce0bb#L11R37
The hypermedia related part of the example is the link building code. The
non-hypermedia related:
> When is findAndSerializeLinksWithoutBreakingLayers(Long) called?
Depends on what the spec leaders would define. Get on
"/client/findAndSerializeLinksWIthoutBreakingLayers" most probably?
> Could you also include a sample XML representation for Client?
Because there is no @Consumes annotation, the id parameter is a query
parameter.
> I'm starting to see some benefits in using Java instead of an external
expression language to build these links. Need to work out some more
examples, though.
I am happy so. The proxy helps on every aspect of the mapping between the
HTTP URI world and the application.
> I think there are very good uses for annotations, and that they
complement rather than supplant XML configurations.
I agree. I can see good and bad points on all of them: programmatic, XML and
annotations. That's why I prefer to give the end user the choice to choose
the best one for him instead of telling him what's the best for all Java EE
projects of the world...
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Mon, Jul 18, 2011 at 1:03 PM, Santiago Pericas-Geertsen <
Santiago.PericasGeertsen_at_oracle.com> wrote:
> Guilherme,
>
> Thanks for sending this. Your example covers a lot of features, I'll start
> commenting on the ones that I find more relevant to the current discussion.
>
> > 2. Serializing links in the controller: not mixing view concerns with
> > the model, leaving it at the controller.
> > Typesafe. Refactor friendly.
> >
> https://github.com/caelum/jaxrs2-caelum/commit/9ba9179e9f2dce71e0a36c8e7c7ab857579ce0bb#L11R37
>
> When is findAndSerializeLinksWithoutBreakingLayers(Long) called? Could you
> also include a sample XML representation for Client?
>
> > 6. Header based link generation
> > This one generates 303, a hyperlink to another part of the system.
> > Again, type safe. Refactor friendly. Non annotation based. No need
> > for an extra description language (that will offer the same limits of
> > other annotation based expression languages):
> >
> https://github.com/caelum/jaxrs2-caelum/commit/9ba9179e9f2dce71e0a36c8e7c7ab857579ce0bb#L11R55
>
> I'm starting to see some benefits in using Java instead of an external
> expression language to build these links. Need to work out some more
> examples, though.
>
> > Of course, the main reason that I see on running away from annotation
> > based languages is that we already have Java. We ran away from XML as
> > a description language for configuration only to arrive at Annotations
> > as a description language for configuration... hmmm..
>
> I think there are very good uses for annotations, and that they complement
> rather than supplant XML configurations.
>
> -- Santiago
>
> > On Wed, Jul 13, 2011 at 11:20 AM, Santiago Pericas-Geertsen
> > <Santiago.PericasGeertsen_at_oracle.com> wrote:
> >> Markus, Guilherme,
> >>
> >>> 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".
> >>
> >> If we don't use something like EL, then I think a Java API sans
> annotations would be preferable. However, I'm not convinced that such an
> alternative provides the same level of ease of use.
> >>
> >> Guilherme: Is there a RestFulie example in which a model is serialized
> using links that we can look at?
> >>
> >> -- Santiago
> >>
> >>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
>
>