users@jersey.java.net

RE: [Jersey] Goals for hypertext constraint support

From: Markus Karg <markus.karg_at_gmx.net>
Date: Thu, 18 Feb 2010 20:04:49 +0100

First of all, sorry for my reaction, but I was kind of tired and possibly
misunderstood one or two phrases.

 

About the goals, well, yes and no. What I would have hoped is that there is
a bit less possibility in the goal for non-RESTful things like RPC-styled
URIs or using self-invented headers (if one wants to do that so badly, he
should abstain from using explicitly a REST framework or stick with JAX-RS
1.1's possibilities I think). Saying that, I would wish the goal of the API
more definitive RESTful "in the inner sense" (to not warm up the discussion
whether it is "in theory" allowed to put a link even in self-invented
headers), which means, it should not support really ANY idea that ANYBODY
might have, but just comes with links in explicitly the "Link" header and
the entity itself, and it is not using by itself URIs that actually look
like method calls (to not make people think that it would be a good idea to
do so). So, moving the responsibility of whether it is RESTful or not to the
user of the framework in my understanding is an invalid target for an API
that is called "Java API for RESTful WebServices", and would be more valid
for something generic like the Servlet API. But hey, this is just my
personal understanding of what the goals should be.

 

From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Donnerstag, 18. Februar 2010 11:45
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Goals for hypertext constraint support

 

Hi Markus,

 

Do you think the goals i presented are reasonable?

 

 

On Feb 17, 2010, at 7:28 PM, Markus Karg wrote:





Paul,

 

About: " Note that i am not interested in abstract philosophical
discussions, nor interested in reverse engineering Roy's thesis, on what is
the hypertext constraint [*]. I personally find such discussions very
distracting, time-consuming, and are better suited for the rest-discuss
email list (which i lurk on but do not participate in because i do not have
the time)."

 

In short: Then skip my postings. ;-)

 

 

:-) that would be inappropriate, i read everything on the list.

 

I just will try and avoid engaging (no matter how tempting!) in such
discussions that i consider are more suited to rest-discuss. I simply do not
have the time. I need to spend time helping Jersey developers with other
issues and fixing stuff. So my time on hypertext can be better spent on the
more concrete aspects of hypertext API details, examples and pointing out
factual errors with specifications, without getting too deeply entangled in
the latter!

 

So i am happy to leave such discussions up to other people on the list and i
am not suggesting that such discussions should not happen. Such discussions
can help towards reaching the goals 1 and 2 (one aim of goal 2 is so we do
not have to repeat such discussions ad-infinitum). My preference is that
such discussions should occur with goals 1 & 2 in mind: that they should
lead to more concrete results in the form of examples and prototypes.

 

Hope that clarifies matters a little more,

Paul.





In long: I agree that discussions can become annoying and theoretical
discussion are better fit in rest-discuss. But I have to disagree with you
assumption that we all have a well understanding of what REST is, and as we
are a community, we should try to change that. "A number", as you wrote, is
just not enough to speak from "community". As this discussion perfectly
showed, there in fact are fundamental differences and shortcomings in what
we understand what REST or HATEOAS is, even at myself, and I am doing REST
since years as you know. Those discussions are needed sometimes to align our
views and understandings of what the target of this project is, and how
tightly it will follow the unique definition of REST or better a practical
approach possibly far aside. As you see, by this discussion I got convinced
that the approach to use the "Link" header is not so bad and I am thankful
for everybody that helped convincing me, including but not limited to Roy,
Craig, Marc, You, Santiago, Jan, etc. I am sure that lots of people followed
the discussion, even the philosophic parts, with great interest. And I am
convinced that it is very good for the project if the community is
discussing heavily, even things you and Marc already discussed long before.
I don't like the idea of a community that just nod through a given proposal
provided by a stakeholder. It might be the case that you disliked the
discussion, but hey, others enjoyed it or just abstained if they did not.
Just skip my postings if you have no time or mood to read them; this is not
your personal email address, it is a community forum in the end. But if you
like to read them, I am happy if you declare your position and enlight me
with your knowledge. :-)

 

Regards

Markus

 

From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Mittwoch, 17. Februar 2010 10:53
To: users_at_jersey.dev.java.net
Subject: [Jersey] Goals for hypertext constraint support

 

On Feb 17, 2010, at 12:36 AM, Tatu Saloranta wrote:


Apologies for beating what may sound like dead horse, but given how
controversial use of seemingly simple terms is, it's necessary to look
beyond acronyms. What are we trying to do here?

 

Goal 1: to design and implement APIs for the client and server side that
make it easier, than it currently is in Jersey, for a developer to apply the
hypertext constraint to their RESTful application.

 

It is the responsibility of the developer to understand the hypertext
constraint and what properties it induces in their application architecture.


 

Goal 2: it is the responsibility of the Jersey team (community? although i
do not think i can speak for the community, only for the team) to help guide
developers with support, examples and documentation.

 

Goal 3: any work we do in Jersey will be input to any future JAX-RS 2.0
effort.

 

To achieve these goals we need to look at existing examples and develop
prototypes to evaluate what is the best way to make progress. We don't want
to limit the API to one particular "pattern" of hypertext constraint
applicable to applications. We want to gather a number of patterns based on
the examples and use-cases.

 

Does the above help clarify matters?

 

 

Note that i am not interested in abstract philosophical discussions, nor
interested in reverse engineering Roy's thesis, on what is the hypertext
constraint [*]. I personally find such discussions very distracting,
time-consuming, and are better suited for the rest-discuss email list (which
i lurk on but do not participate in because i do not have the time).

 

Paul.

 

[*] I think a number of us on this list have a very good understanding on
what the hypertext constraint is and what it aims to achieve.