> > Fielding's dissertation in the inner sense is talking about generic
> clients,
> > like browsers, and it would be cool (and possible) to have one -- if
> I can
> > surf the web with one browser, why should I have special clients for
> REST in
> > common?
>
> Because browsers are "human assisted" and the REST clients that we are
> interested in building (and are the focus of this discussion) are not.
You answered too early. As I just explained to Marc in a different posting,
the idea is to have a generic client triggered by an external driver that
has control of the workflow. So humans play no role, neither in real browser
(which I could theoretically control with an API that tells the browser
where to click) not in a generic REST client.
> This whole idea of a generic REST client that can solve all computing
> problems *without* human intervention is fascinating, unfortunately it
> is just that. I believe you're saying that rather than for every
> service there exist a client (for-all/exist), there exist a client that
> for every service (exist/for-all).
So you mean that a generic REST client will not work? Can you give an
example what shall not work so I can invalidate this thesis?
> Clients need to make decisions to carry out tasks and these decisions
> tend to be service specific, especially those needed in enterprise
> tasks. Thus, the exist/for-all pattern just does not fly *unless* there
> is a human behind to make those decisions, because by definition the
> client cannot possibly know everything about every service out there
> (including those that haven't been invented).
I did never say that there will be no logic that takes decision. In fact, I
said that there shall be a workflow *outside* of the client that runs an
abstract business use case, and that workflow engine *uses* the generic REST
client to do the communication. Just as I can use cURL in a bash script with
lots of IF and ELSE, I could then use a generic client executable that gets
told what link role to search and trigger in the document. The idea is to
decouple the business workflow from the REST client's binary, just as my
wetware has the workflow and the browser has the technology, so the external
driver (Bash, Java, Groovy, whatever) will have the workflow and the generic
REST client has the technology.