Kevin,
it is exactly that confusion that I want to prevent when I am asking people
to clearly follow exactly Fielding's definition but nothing else.
Fielding declared clearly what he meant, just trust his words. Don't get
confused by little technical details we are discussing here: The fact
whether or not links in headers are allowed is just a technical side aspect,
and I am happy that there is a standard coming for the Link header, which is
one of few that actually are allowed to carry links. But the fact that a
server must be stateless is a clear directive of the dissertation.
If you want *everbody* to agree then you need to add HATEOAS (which is
something most will not do, but still claim RESTfulness --which leads to the
discussion and confusion about the word "RESTful", actually).
The question is whether it is actually a business need and practical for you
(which is the topic of my discussion with Santiago): If you just don't need
it, then drop it. Why implementing things you don't need? Only thing you
should not do is putting the label "REST" on it. But who cares about labels,
if you only need is to get a great API?
From: Kevin Duffey [mailto:andjarnic_at_yahoo.com]
Sent: Dienstag, 16. Februar 2010 08:29
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS
actually means)
> Hopefully we can clarify this further with more concrete examples.
I hope soon.. I would really like to know the "right way" to build HATEOAS
apis. :D
I have read this extremely long thread, and am really really confused now as
to what is what. I thought the Sun cloud APIs was a completely restful API
design. However, this notion that the client maintains state has got me a
bit confused now. I would love to see some truly RESTful examples using
Jersey/JAX-RS.. how to implement for example HATEOAS in the present JAX-RS
such that I can claim my API is truly RESTful and that everyone on this
thread would agree on.