Santiago,
answers inlined. :-)
From: Santiago Pericas-Geertsen
[mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Montag, 11. Juli 2011 15:56
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Hypermedia Proposals
On Jul 9, 2011, at 3:59 AM, Markus KARG wrote:
@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.
Markus> I didn't get the point. What shall a condition be good for if there
is no reference? And what shall a Link header be good for if there is no
reference? Both, <a href> and Link: are purely means of transport for
references.
I overloaded the term "reference" too much. See the last example in the
wiki, in which ItemRepresentation does not have a "next" and a "prev" and
conditions are still use for rendering those links. In this case, you
cannot check if "next" or "prev" are null since they are not there. Is that
what you meant by "is null"?
Yes, I meant "is null" in the Java sense. I do not see the need for any
other condition than checking whether the Java reference == null -- which
automatically renders to a missing attribute in XML by default.
@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.
Markus> Yes, but that doesn justify using a String based API in a place
where a compile time check could be made instead. Java EE introduced it
mainly for places where a compile time check is not possible, like in JSPs
(as one can create the references dynamically at runtime there). We should
not turn Java EE into a scripting environment, unless we have a good need
for it. Scripting might be nice for projects where one needs to go live
sooner than later. But our customers instead expect to get high speed and
stability. The latter is better served using compiled syntax.
What is the alternative to EL expressions that you're proposing?
I'd use an interface for that to point to a compiled expression class. I
might be a bit more to type (not with lambda expression in future), but it
can be checked at compile time.
@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?
Markus> No, I am neither using URI or Link in the representation but the
original referenced class. If we are referencing an Apple, the reference
will be using class Apple. This is just natural for Java programmers. Our
current application is using that (using JAXB adapters replacing Apple by
URI and vice versa on the fly). Currently we always replace by URL at
marshalling, but it would be rather simple for us to replace by virtually
anything (like Link). For us, there is clear separation between the data
model (JAXB class) and the transported document (rendered representation).
The data model is an Apple always. But the transferred representation is
either rendered using an "Link Header Renderer" or an "XML URI Renderer".
Again, this works pretty simple with JAXB, but it might get complex for
custom MessageBodyWriters. But, it is the most natural for Java, and so we
should try to do that.
In the example that I showed, there's a model class and a representation
class. @Ref and @Link apply to the latter. What you're suggesting is that
the latter does not need to be defined, but should be inferred? I think
that there are use cases in which the representation (i.e., view) is a
subset of the model, and just working on the model directly may render more
data than what is needed. Perhaps both styles should be supported ...
If you like you can support both styles, but honestly, in the past years
never had a demand for that. See, in the web, there is no difference
between the resource and the representation (a HTML file is a HTML file) so
why introducing it? It just bears complexity without a proof of benefit.
Unless there are clearly defined use case and lots of people demanding it,
we should abstain from having separate classes. See, if one wants to reduce
the amount of XML returned, he simply can apply a filter to run XSLT. No
need to solve that in JAX-RS.
-- 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 <http://bill.burkecentral.com/>