Tatu,
always a pleasure to discuss with you. :-)
About " End goal is not to do perfect HATEOAS system or design (this is not
your service-design-101 college course), but to build functional, robust and
maintainable (or replace with whatever positive adjectives you prefer)
services. ... If the best practical way to do that is to rigorously follow
nicely concise definitions of REST/HATEOAS, so be it, but that is not a
foregone conclusion .":
This actually foils Fielding's dissertation thesis actually: The idea was
that REST is the best solution, since the WWW is RESTful and works so well.
In fact I thought we all want to do REST because we actually believe that
the thesis was right. If we do not, why did we gather do provide especially
a REST API for Java? Why don't we then just open a different project that
provides an even better API and just ignore REST completely (why care about
words if we just need *anything* that is good)? I know this is a rather
philosophic question, but in fact I wonder why you think that REST (which by
definition includes HATEOAS) is not the best fit? I mean, why not doing what
Fielding says BEFORE proposing a different approach?
Regards
Markus
From: Tatu Saloranta [mailto:tsaloranta_at_gmail.com]
Sent: Mittwoch, 17. Februar 2010 00:37
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS
actually means)
n Mon, Feb 15, 2010 at 11:29 PM, Kevin Duffey <andjarnic_at_yahoo.com> wrote:
> 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 was hoping we could expand our thinking beyond HATEOAS actually. :-)
This does not necessarily mean that in the end one does something outside
it, just that focusing on specific discipline puts carriage before horse.
End goal is not to do perfect HATEOAS system or design (this is not your
service-design-101 college course), but to build functional, robust and
maintainable (or replace with whatever positive adjectives you prefer)
services.
If the best practical way to do that is to rigorously follow nicely concise
definitions of REST/HATEOAS, so be it, but that is not a foregone
conclusion. What has been reasonably claimed is that using this principled
approach makes it easier to design scalable systems. But scalability is not
the only concern here: if complexity is moved from server side to client
side it will still need to be tackled somehow. If not using JAX-RS, then
something else. So it is possible (and easy!) to design scalable systems
that do not actually solve the business problems one needs to solve.
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?
-+ Tatu +-