Tatu,
please find answers inlined.
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.
This is not true. What I propose is not a browser with wetware, it actually
is a machine, but the machine behaves like a browser: Agnostic to everything
but taking care only of http, MIME and URIs. If the machine is instructed by
an external trigger (like a calling Java program or bash script) then it
searches for links and invokes http methods. I never had wetware in mind
when talking about the generic REST client, but always an external script
triggering it -- just like a script could atomate cURL or even a browser.
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
This is what I would do first, since I think one should not try to solve a
problem unless it proofs that it actually *is* a problem. Currently this
proof was not provided.
(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.
Nothing against that, but my philosophy is to first do (a) since often (b)
is not more needed then. If there is a proof that (a) will not work, then
you can fallback to (b) later. If you start with (b) first, you will never
know whether (a) had been worked, so you drop possibilities and standards
compliance possibly for the sake of actually nothing.
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.
I personally think that too often proposals target in (b) but not (a)
because people just had no idea to do (a) or discussions about how to make
(a) are stopped to early if people getting out of mood. ;-) It is much
harder to get (a) and we all are lazy programmers so we do (b) right from
the start. But as this project aims in a general framework for the complete
Java universe, we should kick our own ass and discuss to the end and then we
will find that (a) actually is worth doing and much better than (b) and
possibly (b) is not needed at all.
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 +-
I am not saying anything against (b). I just say that as long as "JAX-RS"
stands for "Java API for RESTful WebServices", we should invest our power
into (a) FIRST and if we actually cannot find a solution, THEN to try (B).