They assist because no consistency is required across message boundaries, and the protocol designer must explicitly design server and client to encode the valid life of the message within the message, or design matters such that all messages are cacheable and valid under conditions that are deduceable only from the contents of the message.
REST as an approach to explicit and adaptive handling of CAP issues in protocol design
Marcin Tustin

Interesting. We have been using a similar approach for true blockchain protocols (as opposed to blockchain state machines).

In our approach the server’s data structure is an MDAG ( with interlinked objects and object versions.

In our prototype we use a classic REST API to call up the data between these independent MDAGs and interlink them by UUID referencing. That way the MDAGs are certain to be consistent even between machines.

We go one step further by adding a simple JSON-like schema referencing a functional object (VM executable code) to the REST called objects. That way every server can always know how to interpret the received objects. Even if the original server changes things, the original versions of the objects are still callable and referable though UUID, as well as able to be interpreted by UUID of the functional code.

BTW, we assume that there is no way to keep time in this multi-server system. Currently each server provides a list of other servers which are ordering its data stream. We are currently working on implementing a Universal Hash Time POC ( so that all participating servers can find out the absolute order of object events across all servers without assuming time keeping capability.

Show your support

Clapping shows how much you appreciated Taulant Ramabaja’s story.