The problem with the example is that is is using hypermedia, but it is not
using REST in the inner sense: In a RESTful architecture, the server would
not store any information between two calls (stateless), so it will only
serve as a machine that processes the information uploaded and give back the
processed result. The example in contrast is targeting a server that has
full control, where the client is just triggering jobs, which clearly would
be RPC and is not RESTful.
If we misunderstood this (which might be possible) then it would be good if
you could elaborate on the documents uploaded and downloaded in every step,
so we could better see the stateless aspect.
Voice to voice is problematic since we both are no native speakers and -at
last myself- needs some time to read your answers to understand them and to
find the right words to answer.
However, i do not see why the current approach cannot do some business level
stuff too (although i am not stating that it is the best way for such
business level stuff). The prototype example presents a workflow to the
client via hypermedia, just in a different form to links in documents. Maybe
what you are saying is this approach does not work very well for business
level requirements?
I must admit to having trouble understanding what you do not understand :-)
so this brings me back to the need for an equivalent concrete example and
then we can compare. Plus having a voice to voice or face to face chat would
i think clear up a lot of matters.
Hmm, interestingly I have worked last year on such a technical API,
including things like explicit locking and what I came up with is maybe
(will check) pretty comparable to what you guys are doing.
Ah, this could be good news :-)
So we may have two use cases: "technical APIs" (for want of a better word);
and "business level process".
Paul.