Rename standard RPCs to look more RESTful. (#1290)

Author: eddyashton

doc/members/accept_recovery.rst

@@ -42,28 +42,28 @@ To restore private transactions and complete the recovery procedure, members sho
 
 .. note:: The members who submit their recovery shares do not necessarily have to be the members who previously accepted the recovery.
 
-First, members should retrieve their encrypted recovery shares via the ``getEncryptedRecoveryShare`` RPC [#recovery_share]_.
+First, members should retrieve their encrypted recovery shares via the ``recovery_share`` RPC [#recovery_share]_.
 
 .. code-block:: bash
 
-    $ curl https://<ccf-node-address>/members/getEncryptedRecoveryShare -X GET --cacert network_cert --key member1_privk --cert member1_cert -H "content-type: application/json"
+    $ curl https://<ccf-node-address>/members/recovery_share -X GET --cacert network_cert --key member1_privk --cert member1_cert -H "content-type: application/json"
 
 Then, members should decrypt their shares using their private encryption key and the `previous` network public encryption key (output by the first node of the now-defunct service via the ``network-enc-pubk-file`` :ref:`command line option <operators/start_network:Starting the First Node>`) using `NaCl's public-key authenticated encryption <https://nacl.cr.yp.to/box.html>`_.
 
-Finally, members should submit their decrypted share to CCF via the ``submitRecoveryShare`` RPC:
+Finally, members should submit their decrypted share to CCF via the ``recovery_share/submit`` RPC:
 
 .. code-block:: bash
 
     $ cat submit_recovery_share.json
     {"recovery_share": [<recovery_share_bytes>]}
 
-    $ curl https://<ccf-node-address>/members/submitRecoveryShare -X POST --data-binary @submit_recovery_share.json --cacert network_cert --key member1_privk --cert member1_cert -H "content-type: application/json"
+    $ curl https://<ccf-node-address>/members/recovery_share/submit -X POST --data-binary @submit_recovery_share.json --cacert network_cert --key member1_privk --cert member1_cert -H "content-type: application/json"
     false
 
-    $ curl https://<ccf-node-address>/members/submitRecoveryShare -X POST --data-binary @submit_recovery_share.json --cacert network_cert --key member2_privk --cert member2_cert -H "content-type: application/json"
+    $ curl https://<ccf-node-address>/members/recovery_share/submit -X POST --data-binary @submit_recovery_share.json --cacert network_cert --key member2_privk --cert member2_cert -H "content-type: application/json"
     true
 
-When the recovery threshold is reached, the ``submitRecoveryShare`` RPC returns ``true``. At this point, the private recovery procedure is started and the private ledger is being recovered.
+When the recovery threshold is reached, the ``recovery_share/submit`` RPC returns ``true``. At this point, the private recovery procedure is started and the private ledger is being recovered.
 
 .. note:: While all nodes are recovering the private ledger, no new transaction can be executed by the network.
 
@@ -91,16 +91,16 @@ Summary Diagram
         Node 2-->>Member 1: State: ACCEPTED
         Note over Node 2, Node 3: accept_recovery proposal completes. Service is ready to accept recovery shares.
 
-        Member 0->>+Node 2: getEncryptedRecoveryShare
+        Member 0->>+Node 2: recovery_share
         Node 2-->>Member 0: Encrypted recovery share for Member 0
         Note over Member 0: Decrypts recovery share
-        Member 0->>+Node 2: submitRecoveryShare: {"recovery_share": ...}
+        Member 0->>+Node 2: recovery_share/submit: {"recovery_share": ...}
         Node 2-->>Member 0: False
 
-        Member 1->>+Node 2: getEncryptedRecoveryShare
+        Member 1->>+Node 2: recovery_share
         Node 2-->>Member 1: Encrypted recovery share for Member 1
         Note over Member 1: Decrypts recovery share
-        Member 1->>+Node 2: submitRecoveryShare: {"recovery_share": ...}
+        Member 1->>+Node 2: recovery_share/submit: {"recovery_share": ...}
         Node 2-->>Member 1: True
 
         Note over Node 2, Node 3: Reading Private Ledger...

doc/members/adding_member.rst

@@ -39,17 +39,17 @@ Activating a New Member
 
 A new member who gets registered in CCF is not yet able to participate in governance operations. To do so, the new member should first acknowledge that they are satisfied with the state of the service (for example, after auditing the current constitution and the nodes currently trusted).
 
-First, the new member should update and retrieve the latest state digest via the ``members/updateAckStateDigest`` command. In doing so, the new member confirms that they are satisfied with the current state of the service.
+First, the new member should update and retrieve the latest state digest via the ``members/ack/update_state_digest`` command. In doing so, the new member confirms that they are satisfied with the current state of the service.
 
 .. code-block:: bash
 
-    $ curl https://<ccf-node-address>/members/updateAckStateDigest  --cacert networkcert.pem --key new_member_privk.pem --cert new_member_cert.pem
+    $ curl https://<ccf-node-address>/members/ack/update_state_digest  --cacert networkcert.pem --key new_member_privk.pem --cert new_member_cert.pem
     {
         "state_digest": <...>
     }
 
 
-Then, the new member should sign the state digest returned by the ``members/updateAckStateDigest`` via the ``members/ack`` command, using the ``scurl.sh`` utility:
+Then, the new member should sign the state digest returned by the ``members/ack/update_state_digest`` via the ``members/ack`` command, using the ``scurl.sh`` utility:
 
 .. code-block:: bash
 

doc/members/member_rpc_api.rst

@@ -43,10 +43,10 @@ read
 .. literalinclude:: ../schemas/read_result.json
     :language: json
 
-updateAckStateDigest
+ack/update_state_digest
 --------------------
 
-.. literalinclude:: ../schemas/updateAckStateDigest_result.json
+.. literalinclude:: ../schemas/ack/update_state_digest_result.json
     :language: json
 
 vote
@@ -65,16 +65,16 @@ withdraw
 .. literalinclude:: ../schemas/withdraw_result.json
     :language: json
 
-getEncryptedRecoveryShare
+recovery_share
 -------------------------
 
-.. literalinclude:: ../schemas/getEncryptedRecoveryShare_result.json
+.. literalinclude:: ../schemas/recovery_share_result.json
     :language: json
 
-submitRecoveryShare
+recovery_share/submit
 -------------------
 
-.. literalinclude:: ../schemas/submitRecoveryShare_params.json
+.. literalinclude:: ../schemas/recovery_share/submit_params.json
     :language: json
-.. literalinclude:: ../schemas/submitRecoveryShare_result.json
+.. literalinclude:: ../schemas/recovery_share/submit_result.json
     :language: json

doc/operators/operator_rpc_api.rst

@@ -3,12 +3,12 @@ Operator RPC API
 
 As well as the following methods, :ref:`users/rpc_api:Common Methods` are also available to operators.
 
-getQuote
---------
+quote
+-----
 
 Retrieves quote of single contacted node.
 
-.. literalinclude:: ../schemas/getQuote_result.json
+.. literalinclude:: ../schemas/quote_result.json
     :language: json
 
 Example
@@ -26,12 +26,12 @@ Example
         ]
     }
 
-getQuotes
----------
+quotes
+------
 
 Retrieves quotes of all trusted nodes.
 
-.. literalinclude:: ../schemas/getQuotes_result.json
+.. literalinclude:: ../schemas/quotes_result.json
     :language: json
 
 Example
@@ -54,8 +54,8 @@ Example
         ]
     }
 
-getSignedIndex
---------------
+signed_index
+------------
 
 .. literalinclude:: ../schemas/getSignedIndex_result.json
     :language: json

doc/operators/recovery.rst

@@ -31,9 +31,9 @@ To initiate the first phase of the recovery procedure, one or several nodes shou
     recover
     --network-cert-file /path/to/network_certificate
 
-Each node will then immediately restore the public entries of its ledger (``--ledger-dir``). Because deserialising the public entries present in the ledger may take some time, operators can query the progress of the public recovery by calling ``getSignedIndex`` which returns the version of the last signed recovered ledger entry. Once the public ledger is fully recovered, the recovered node automatically becomes part of the public network, allowing other nodes to join the network.
+Each node will then immediately restore the public entries of its ledger (``--ledger-dir``). Because deserialising the public entries present in the ledger may take some time, operators can query the progress of the public recovery by calling ``signed_index`` which returns the version of the last signed recovered ledger entry. Once the public ledger is fully recovered, the recovered node automatically becomes part of the public network, allowing other nodes to join the network.
 
-.. note:: If more than one node were started in ``recover`` mode, the node with the highest signed index (as per the response to the ``getSignedIndex`` RPC) should be preferred to start the new network. Other nodes should be shutdown and new nodes restarted with the ``join`` option.
+.. note:: If more than one node were started in ``recover`` mode, the node with the highest signed index (as per the response to the ``signed_index`` RPC) should be preferred to start the new network. Other nodes should be shutdown and new nodes restarted with the ``join`` option.
 
 Similarly to the normal join protocol (see :ref:`operators/start_network:Adding a New Node to the Network`), other nodes are then able to join the network.
 
@@ -48,10 +48,10 @@ Similarly to the normal join protocol (see :ref:`operators/start_network:Adding
         Node 2-->>Operators: Network Certificate
         Note over Node 2: Reading Public Ledger...
 
-        Operators->>+Node 2: getSignedIndex
+        Operators->>+Node 2: signed_index
         Node 2-->>Operators: {"signed_index": 50, "state": "readingPublicLedger"}
         Note over Node 2: Finished Reading Public Ledger, now Part of Public Network
-        Operators->>Node 2: getSignedIndex
+        Operators->>Node 2: signed_index
         Node 2-->>Operators: {"signed_index": 243, "state": "partOfPublicNetwork"}
 
         Note over Operators, Node 2: Operators select Node 2 to start the new network

…schemas/updateAckStateDigest_result.json …emas/ack/update_state_digest_result.jsondoc/schemas/updateAckStateDigest_result.json renamed to doc/schemas/ack/update_state_digest_result.json doc/schemas/updateAckStateDigest_result.json renamed to doc/schemas/ack/update_state_digest_result.json

@@ -13,6 +13,6 @@
   "required": [
     "state_digest"
   ],
-  "title": "updateAckStateDigest/result",
+  "title": "ack/update_state_digest/result",
   "type": "object"
 }

doc/schemas/getSchema_params.json doc/schemas/api/schema_params.jsondoc/schemas/getSchema_params.json renamed to doc/schemas/api/schema_params.json

@@ -8,6 +8,6 @@
   "required": [
     "method"
   ],
-  "title": "getSchema/params",
+  "title": "api/schema/params",
   "type": "object"
 }

doc/schemas/getSchema_result.json doc/schemas/api/schema_result.jsondoc/schemas/getSchema_result.json renamed to doc/schemas/api/schema_result.json

@@ -12,6 +12,6 @@
     "params_schema",
     "result_schema"
   ],
-  "title": "getSchema/result",
+  "title": "api/schema/result",
   "type": "object"
 }

doc/schemas/listMethods_result.json doc/schemas/api_result.jsondoc/schemas/listMethods_result.json renamed to doc/schemas/api_result.json

@@ -11,6 +11,6 @@
   "required": [
     "methods"
   ],
-  "title": "listMethods/result",
+  "title": "api/result",
   "type": "object"
 }

doc/schemas/getMetrics_result.json doc/schemas/metrics_result.jsondoc/schemas/getMetrics_result.json renamed to doc/schemas/metrics_result.json

@@ -40,6 +40,6 @@
     "histogram",
     "tx_rates"
   ],
-  "title": "getMetrics/result",
+  "title": "metrics/result",
   "type": "object"
 }