|Did you know ...||Search Documentation:|
|Pack canny_tudor -- prolog/paxos/http_handlers.pl|
These handlers spool up a JSON-based HTTP interface to the Paxos predicates, namely
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.
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.