On Wed, Feb 17, 2010 at 10:12 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
> Tatu,
>
>
>
> always a pleasure to discuss with you. :-)
>
>
:-)
Discussions are like bitter medicine sometimes. But generally good for you,
even if initial taste made your tongue tingle.
>
>
> 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
>
Yes, I agree. And I think that its power really is in its simplicity, and it
being a principled approach. Not just what works, but what can be described
and even prescribed. Sort of like how RISC (long time ago) took over CPU
design (sorry I digress), Agile methodologies for development and so on.
My specific concerns however are with non-browser-based approaches.
Many/most use cases seem to assume that systems have browser (or some
directly human-operated component) as an integral part, which allows
offloading of much of complexity to "wetware". This is not the case for most
systems I design and implement; and it seems that this is where plain REST
approach would not fit well.
Maybe because b2b systems are not WWW as commonly understood.
> 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?
>
>
>
I think there are two possibilities here, and I do not claim to know which
one is right (or even if either):
(a) Use REST -- exactly as prescribed -- for server-side and client-side, to
tackle some of the issues. Bit like how Unicode (UTF-8) can handle some
aspects of textual processing, from standardization of characters to
standardization of efficient encoding. And leave other problems to be solved
at higher level and/or out-of-scope
(b) Extract some of basic REST ideas -- use of HTTP as a simple and
good-enough protocol; idea of resources as the focal point, and so on -- and
try to extend model with more stateful approaches. Hybrid if you will.
I agree in that above is vague, and that I do not have concrete offer for
how to approach (b). But I think many Jersey proposals are more geared
towards (b) than (a); partly because (a) would really imply that extensions
should be out of scope, done within context of related but separate
projects.
Does this make sense? So: I am not against REST, I just want to emphasize
that yet another logical extension is to consider non-REST alternatives or
extensions. Not claiming that they are REST if they are not (in this I think
I fully agree with you), but not dismissing them just on that basis.
-+ Tatu +-