[GNUnet-SVN] [taler-api] 07/22: Nothing but APIs under api.taler.net

[gnunet]

This is an automated email from the git hooks/post-receive script.

marcello pushed a commit to branch master
in repository api.

commit 3569ab1443bba65702d70d83b3c5f3a7fd27ebc4
Author: Marcello Stanisci <address@hidden>
AuthorDate: Mon Dec 26 23:44:22 2016 +0100

    Nothing but APIs under api.taler.net
---
 api/index.rst                | 29 -----------------------------
 docs/example-essay-store.rst | 21 ++++++++++++---------
 docs/operate-exchange.rst    |  7 +++++--
 docs/operate-merchant.rst    | 14 ++++++--------
 4 files changed, 23 insertions(+), 48 deletions(-)

diff --git a/api/index.rst b/api/index.rst
index 01724fd..9e49818 100644
--- 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
index 8ba28df..1d533d9 100644
--- 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
index 874b837..38293bb 100644
--- 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
index 484d6eb..7f88a00 100644
--- 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

-- 
To stop receiving notification emails like this one, please contact
address@hidden