Merge pull request #1532 from bigchaindb/feat/1531/consistent-naming

Consistent naming of `transaction_id`

docs/server/source/data-models/inputs-outputs.rst

@@ -133,7 +133,7 @@ If there is only one *current owner*, the fulfillment will be a simple signature
         "fulfillment": "cf:4:RxFzIE679tFBk8zwEgizhmTuciAylvTUwy6EL6ehddHFJOhK5F4IjwQ1xLu2oQK9iyRCZJdfWAefZVjTt3DeG5j2exqxpGliOPYseNkRAWEakqJ_UrCwgnj92dnFRAEE",
         "fulfills": {
             "output": 0,
-            "txid": "11b3e7d893cc5fdfcf1a1706809c7def290a3b10b0bef6525d10b024649c42d3"
+            "transaction_id": "11b3e7d893cc5fdfcf1a1706809c7def290a3b10b0bef6525d10b024649c42d3"
         }
     }
 
@@ -152,7 +152,7 @@ If there are multiple *current owners*, the fulfillment will be a little differe
         "fulfillment": "cf:2:AQIBAgEBYwAEYEv6O5HjHGl7OWo2Tu5mWcWQcL_OGrFuUjyej-dK3LM99TbZsRd8c9luQhU30xCH5AdNaupxg-pLHuk8DoSaDA1MHQGXUZ80a_cV-4UaaaCpdey8K0CEcJxre0X96hTHCwABAWMABGBnsuHExhuSj5Mdm-q0KoPgX4nAt0s00k1WTMCzuUpQIp6aStLoTSMlsvS4fmDtOSv9gubekKLuHTMAk-LQFSKF1JdzwaVWAA2UOv0v_OS2gY3A-r0kRq8HtzjYdcmVswUA",
         "fulfills": {
             "output": 0,
-            "txid": "e4805f1bfc999d6409b38e3a4c3b2fafad7c1280eb0d441da7083e945dd89eb8"
+            "transaction_id": "e4805f1bfc999d6409b38e3a4c3b2fafad7c1280eb0d441da7083e945dd89eb8"
         }
     }
 
@@ -161,4 +161,4 @@ If there are multiple *current owners*, the fulfillment will be a little differe
 - ``fulfillment``: A crypto-conditions URI that encodes the cryptographic fulfillments like signatures and others;'cf' indicates this is a fulfillment, '2' indicates the condition type is THRESHOLD-SHA-256 (while '4' in `One Current Owner`_ indicates its condition type is ED25519).
 - ``fulfills``: Pointer to an output from a previous transaction that is being spent
     - ``output``: The index of the output in a previous transaction
-    - ``txid``: ID of the transaction
+    - ``transaction_id``: ID of the transaction

docs/server/source/http-client-server-api.rst

@@ -42,9 +42,9 @@ that allows you to discover the BigchainDB API endpoints:
 Transactions
 -------------------
 
-.. http:get:: /api/v1/transactions/{tx_id}
+.. http:get:: /api/v1/transactions/{transaction_id}
 
-   Get the transaction with the ID ``tx_id``.
+   Get the transaction with the ID ``transaction_id``.
 
    This endpoint returns a transaction if it was included in a ``VALID`` block.
    All instances of a transaction in invalid/undecided blocks or the backlog
@@ -53,8 +53,8 @@ Transactions
    invalid/undecided blocks or the backlog, then the response will be ``404 Not
    Found``.
 
-   :param tx_id: transaction ID
-   :type tx_id: hex string
+   :param transaction_id: transaction ID
+   :type transaction_id: hex string
 
    **Example request**:
 
@@ -215,19 +215,19 @@ Statuses
    A link to the resource is also provided in the returned payload under
    ``_links``.
 
-   :query string tx_id: transaction ID
+   :query string transaction_id: transaction ID
    :query string block_id: block ID
 
    .. note::
 
-        Exactly one of the ``tx_id`` or ``block_id`` query parameters must be
+        Exactly one of the ``transaction_id`` or ``block_id`` query parameters must be
         used together with this endpoint (see below for getting `transaction
         statuses <#get--statuses?tx_id=tx_id>`_ and `block statuses
         <#get--statuses?block_id=block_id>`_).
 
 .. _get_status_of_transaction:
 
-.. http:get:: /api/v1/statuses?tx_id={tx_id}
+.. http:get:: /api/v1/statuses?transaction_id={transaction_id}
 
     Get the status of a transaction.
 
@@ -298,8 +298,8 @@ Assets
 
 .. http:get:: /api/v1/assets?search={text_search}
 
-    Return all assets that match a given text search. The asset is returned
-    with the ``id`` of the transaction that created the asset.
+    Return all assets that match a given text search. The ``id`` of the asset
+    is the same ``id`` of the transaction that created the asset.
 
     If no assets match the text search it returns an empty list.
 
@@ -398,12 +398,12 @@ Advanced Usage
 The following endpoints are more advanced and meant for debugging and transparency purposes.
 
 More precisely, the `blocks endpoint <#blocks>`_ allows you to retrieve a block by ``block_id`` as well the list of blocks that
-a certain transaction with ``tx_id`` occured in (a transaction can occur in multiple ``invalid`` blocks until it
+a certain transaction with ``transaction_id`` occured in (a transaction can occur in multiple ``invalid`` blocks until it
 either gets rejected or validated by the system). This endpoint gives the ability to drill down on the lifecycle of a
 transaction
 
 The `votes endpoint <#votes>`_ contains all the voting information for a specific block. So after retrieving the
-``block_id`` for a given ``tx_id``, one can now simply inspect the votes that happened at a specific time on that block.
+``block_id`` for a given ``transaction_id``, one can now simply inspect the votes that happened at a specific time on that block.
 
 
 Blocks
@@ -439,8 +439,8 @@ Blocks
 .. http:get:: /api/v1/blocks
 
    The unfiltered ``/blocks`` endpoint without any query parameters returns a `400` status code.
-   The list endpoint should be filtered with a ``tx_id`` query parameter,
-   see the ``/blocks?tx_id={tx_id}&status={UNDECIDED|VALID|INVALID}``
+   The list endpoint should be filtered with a ``transaction_id`` query parameter,
+   see the ``/blocks?transaction_id={transaction_id}&status={UNDECIDED|VALID|INVALID}``
    `endpoint <#get--blocks?tx_id=tx_id&status=UNDECIDED|VALID|INVALID>`_.
 
 
@@ -459,9 +459,9 @@ Blocks
 
    :statuscode 400: The request wasn't understood by the server, e.g. just requesting ``/blocks`` without the ``block_id``.
 
-.. http:get:: /api/v1/blocks?tx_id={tx_id}&status={UNDECIDED|VALID|INVALID}
+.. http:get:: /api/v1/blocks?transaction_id={transaction_id}&status={UNDECIDED|VALID|INVALID}
 
-   Retrieve a list of ``block_id`` with their corresponding status that contain a transaction with the ID ``tx_id``.
+   Retrieve a list of ``block_id`` with their corresponding status that contain a transaction with the ID ``transaction_id``.
 
    Any blocks, be they ``UNDECIDED``, ``VALID`` or ``INVALID`` will be
    returned if no status filter is provided.
@@ -470,7 +470,7 @@ Blocks
        In case no block was found, an empty list and an HTTP status code
        ``200 OK`` is returned, as the request was still successful.
 
-   :query string tx_id: transaction ID *(required)*
+   :query string transaction_id: transaction ID *(required)*
    :query string status: Filter blocks by their status. One of ``VALID``, ``UNDECIDED`` or ``INVALID``.
 
    **Example request**:
@@ -485,8 +485,8 @@ Blocks
 
    :resheader Content-Type: ``application/json``
 
-   :statuscode 200: A list of blocks containing a transaction with ID ``tx_id`` was found and returned.
-   :statuscode 400: The request wasn't understood by the server, e.g. just requesting ``/blocks``, without defining ``tx_id``.
+   :statuscode 200: A list of blocks containing a transaction with ID ``transaction_id`` was found and returned.
+   :statuscode 400: The request wasn't understood by the server, e.g. just requesting ``/blocks``, without defining ``transaction_id``.
 
 
 Votes

docs/server/source/websocket-event-stream-api.rst

@@ -32,7 +32,7 @@ response contains a ``streams`` property:
 
     {
      ...,
-     "streams": "ws://example.com:9985/api/v1/streams/valid_tx",
+     "streams": "ws://example.com:9985/api/v1/streams/valid_transactions",
      ...
     }
 
@@ -56,8 +56,8 @@ BigchainDB node will be ignored.
 Streams will always be under the WebSocket protocol (so ``ws://`` or
 ``wss://``) and accessible as extensions to the ``/api/v<version>/streams/``
 API root URL (for example, `validated transactions <#valid-transactions>`_
-would be accessible under ``/api/v1/streams/valid_tx``). If you're running your
-own BigchainDB instance and need help determining its root URL,
+would be accessible under ``/api/v1/streams/valid_transactions``). If you're
+running your own BigchainDB instance and need help determining its root URL,
 then see the page titled :ref:`Determining the API Root URL`.
 
 All messages sent in a stream are in the JSON format.
@@ -77,7 +77,7 @@ All messages sent in a stream are in the JSON format.
 Valid Transactions
 ~~~~~~~~~~~~~~~~~~
 
-``/valid_tx``
+``/valid_transactions``
 
 Streams an event for any newly validated transactions. Message bodies contain
 the transaction's ID, associated asset ID, and containing block's ID.
@@ -87,7 +87,7 @@ Example message:
 .. code:: JSON
 
     {
-        "tx_id": "<sha3-256 hash>",
+        "transaction_id": "<sha3-256 hash>",
         "asset_id": "<sha3-256 hash>",
         "block_id": "<sha3-256 hash>"
     }
@@ -98,6 +98,6 @@ Example message:
     Transactions in BigchainDB are validated in batches ("blocks") and will,
     therefore, be streamed in batches. Each block can contain up to a 1000
     transactions, ordered by the time at which they were included in the block.
-    The ``/valid_tx`` stream will send these transactions in the same order
-    that the block stored them in, but this does **NOT** guarantee that you
-    will recieve the events in that same order.
+    The ``/valid_transactions`` stream will send these transactions in the same
+    order that the block stored them in, but this does **NOT** guarantee that
+    you will recieve the events in that same order.