commit 3569ab1443bba65702d70d83b3c5f3a7fd27ebc4
parent 26589150d9e5788f99ba31f710616e7aca2b1ee7
Author: Marcello Stanisci <marcello.stanisci@inria.fr>
Date: Mon, 26 Dec 2016 23:44:22 +0100
Nothing but APIs under api.taler.net
Diffstat:
4 files changed, 23 insertions(+), 48 deletions(-)
diff --git a/api/index.rst b/api/index.rst
@@ -41,35 +41,6 @@ In this document, we describe the REST-based APIs between the various
components, internal architecture of key components, and how to get them
installed.
--------
-Preface
--------
-
-The *Operator Handbook* is for people who want to run a exchange or a merchant.
-It focuses on how to install, configure and run the required software.
-
-.. toctree::
- :maxdepth: 2
-
- global_licensing
- versioning
-
-------------------------
-Web Integration Handbook
-------------------------
-
-The *Web Integration Handbook* is for those who want to interact with Taler
-wallets on their own website. Integrators will also have to be familiar with
-the material covered in the *Operator Handbook*.
-
-
-.. toctree::
- :maxdepth: 2
-
- integration-general
- integration-bank
- integration-merchant
-
--------------------------------------
Taler HTTP Core Protocol Specification
--------------------------------------
diff --git a/docs/example-essay-store.rst b/docs/example-essay-store.rst
@@ -30,7 +30,8 @@ https://git.taler.net/merchant-frontends.git/tree/talerfrontends/blog
and is implemented in Python+Flask.
The desired effect is the homepage showing a list of buyable articles, and once the
-user clicks one of them, they will either get the Taler :ref:`contract <contract>`
+user clicks one of them, they will either get the Taler
+`contract <https://api.taler.net/api-merchnat.html#contract>`_
or a credit card paywall if they have no Taler wallet installed.
Each article links thus to a `offer URL`, having the following
@@ -248,10 +249,12 @@ for the contract, the transaction ID, and the article name; respectively,
``now``, ``tid``, and ``article_name``.
After ``make_contract`` returns, the variable ``contract`` will hold a
-`dict` type that complies with a contract :ref:`proposition <proposition>`.
+`dict` type that complies with a contract
+`proposition <https://api.taler.net/api-merchnat.html#proposition>`_
We then call ``sign_contract`` feeding it with the proposition, so that
it can forward it to the backend and return it signed. Finally we return
-the signed proposition, complying with the :ref:`Offer <contract>` object.
+the signed proposition, complying with the
+`Offer <https://api.taler.net/api-merchant.html#contract>`_ object.
For simplicity, any article costs the same price, so the frontend
doesn't need to map articles to prices.
@@ -300,10 +303,10 @@ fulfillment URL parameters. See below the URL layout:
The way the contract is reconstructed is exactly the same as it was generated
in the previous steps: we need to call ``make_contract`` to get the original
-:ref:`proposition <proposition>` and then ``sign_contract``. Recall that aside
-from allowing the backend to add missing fields to the proposition, ``sign_contract``
-returns the contract hashcode also, that we should compare with the ``uuid``
-parameter provided by the wallet.
+`proposition <https://api.taler.net/api-merchnat.html#proposition>`_ and then
+``sign_contract``. Recall that aside from allowing the backend to add missing
+fields to the proposition, ``sign_contract`` returns the contract hashcode also,
+that we should compare with the ``uuid`` parameter provided by the wallet.
In our blog, all the fulfillment logic is implemented in the function ``article``,
defined in ``talerfrontends/blog/blog.py``. It is important to note that this
@@ -551,8 +554,8 @@ Pay logic
---------
The pay handler for the blog is implemented by the function
-``pay`` at ``talerfrontends/blog/blog.py``. Its main duty is
-to receive the :ref:`deposit permission <DepositPermission>`
+``pay`` at ``talerfrontends/blog/blog.py``. Its main duty is to receive the
+`deposit permission <https://api.taler.net/api-merchant.html#DepositPermission>`_
from the wallet, forward it to the backend, and return the outcome
to the wallet. See below the main steps of its implementation.
diff --git a/docs/operate-exchange.rst b/docs/operate-exchange.rst
@@ -106,12 +106,15 @@ For example, the utility may be invoked as follows::
Note that the value given to option `-t` must match the value in the JSON's field ``"type"``.
-The generated file will be echoed by the exchange when serving :ref:`/wire <wire-req>` requests.
+The generated file will be echoed by the exchange when serving
+`/wire <https://api.taler.net/api-exchange.html#wire-req>`_
+requests.
Outgoing
^^^^^^^^
-This exchange's bank account is used to give money to merchants, after successful :ref:`deposits <deposit-par>`
+This exchange's bank account is used to give money to merchants, after successful
+`deposits <https://api.taler.net/api-exchange.html#deposit-par>`_
operations. If `test` is the chosen wireformat, the outcoming bank account is configured by the following
options under `[exchange-wire-outcoming-test]`:
diff --git a/docs/operate-merchant.rst b/docs/operate-merchant.rst
@@ -88,7 +88,8 @@ pattern::
schema://hostname/
-`master_key` is the base32 encoding of the exchange's master key (see :ref:`/keys <keys>`).
+`master_key` is the base32 encoding of the exchange's master key
+(see `/keys <https://api.taler.net/api-exchange.html#keys>`_).
In our demo, we use the following configuration::
[merchant-exchange-test]
@@ -180,18 +181,15 @@ instance `Tor` as follows::
[merchant-instance-wireformat-Tor]
TEST_RESPONSE_FILE = ${TALER_CONFIG_HOME}/merchant/wire/tor.json
-Please note that :ref:`Taler messagging<merchant-api>` is designed so that the merchant
-frontend can instruct the backend on which instance has to be used in the various operations.
-This information is optional, and if not given, the backend will act as the `default` instance.
+Please note that `Taler messagging <https://api.taler.net/api-merchant.html#merchant-api>`_
+is designed so that the merchant frontend can instruct the backend on which instance has to
+be used in the various operations. This information is optional, and if not given,
+the backend will act as the `default` instance.
++++++++++++
Installation
++++++++++++
-
-
-
-
In order to compile your merchant backend, you firstly need to install the GNU Taler
exchange. As of other dependencies, the merchant backend needs exactly the same ones
as the exchange does. Follow :ref:`those instructions <exchange-install>` to build
