These handlers spool up a JSON-based HTTP interface to the Paxos predicates, namely

• paxos_property/1 as JSON object on GET at /paxos/properties,
• paxos_get/2 as arbitrary JSON on GET at /paxos/Key and
• paxos_set/2 as arbitrary JSON on POST at /paxos/Key

Take the example below. Uses http_server/1 to start a HTTP server on some given port.

?- [library(http/http_server), library(http/http_client)].
true.

?- http_server([port(8080)]).
% Started server at http://localhost:8080/
true.

?- http_get('http://localhost:8080/paxos/properties', A, []).
A = json([node=0, quorum=1, failed=0]).

Getting and setting using JSON encoding works as follows.

?- http_get('http://localhost:8080/paxos/hello', A, [status_code(B)]).
A = '',
B = 204.

?- http_post('http://localhost:8080/paxos/hello', json(world), A, []).
A = @true.

?- http_get('http://localhost:8080/paxos/hello', A, [status_code(B)]).
A = world,
B = 200.

Note that the initial GET fails. It replies with the empty atom since no content exists. Predicate paxos_get/2 is semi-deterministic; it can fail. Empty atom is not valid Prolog-encoding for JSON. Status code of 204 indicates no content. The Paxos ledger does not contain data for that key.

Thereafter, POST writes a string value for the key and a repeated GET attempt now answers the new consensus data. Status code 200 indicates a successful ledger concensus.

Serialisation

Serialises unknowns. Paxos ledgers may contain non-JSON compatible data. Anything that does not correctly serialise as JSON becomes an atomicly rendered Prolog term. Take a consensus value of term a(1) for example; GET requests see "a(1)" as a rendered Prolog string. The ledger comprises Prolog terms, fundamentally, rather than JSON-encoded strings.

Setting a Paxos value reads JSON from the POST request body. It can be any valid JSON value including atomic values as well as objects and arrays.