mirror of
https://github.com/bigchaindb/bigchaindb.git
synced 2024-10-13 13:34:05 +00:00
Merge pull request #1532 from bigchaindb/feat/1531/consistent-naming
Consistent naming of `transaction_id`
This commit is contained in:
@@ -76,7 +76,7 @@ Content-Type: application/json
|
||||
|
||||
|
||||
TPLS['get-statuses-tx-request'] = """\
|
||||
GET /statuses?tx_id=%(txid)s HTTP/1.1
|
||||
GET /statuses?transaction_id=%(txid)s HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
"""
|
||||
@@ -151,7 +151,7 @@ Content-Type: application/json
|
||||
|
||||
|
||||
TPLS['get-block-txid-request'] = """\
|
||||
GET /api/v1/blocks?tx_id=%(txid)s HTTP/1.1
|
||||
GET /api/v1/blocks?transaction_id=%(txid)s HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
"""
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user