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 +-