The implicit and generally overlooked actor of the REST based systems is the client. REST requires a semantic client that reads the provided resource lists. The

The implicit and generally overlooked actor of the REST based systems is the client. REST requires a semantic client that reads the provided resource lists. The germinal idea behind REST was an appreciation of WWW as an ad hoc distributed system resilient to various fault modalities where unknown clients collaborated with known servers, using only a hypertext protocol. How did this work and how can it be generalized? That is the REST dissertation. A REST system for domain X naturally requires design for a finite state machine client that can infer semantics for the resources in domain X. In general WWW, the client is a browser + a human being that reads links. Once you remove the human semantic processor of this equations while retaining capability, the client rapidly increases in complexity, if at all possible. Is it natural to think of ("mutating stateful!") systems? It is difficult and somewhat out of phase to be server centric. But if you think in terms of a smart client for domain X, map out the app's capabilities, and then map resources in domain X you need to fulfill capability C, then REST is a perfectly natural way to consider systems, in an end-user centric approach to system design, for a specific domain.