From 57b336ddbf748174ec93f6cf0d5bcebb6a62ee51 Mon Sep 17 00:00:00 2001 From: Patrick O'Grady Date: Sat, 8 Aug 2020 12:53:15 -0700 Subject: [PATCH] Better solution --- api.json | 9 +-------- api.yaml | 24 ++++++++++-------------- 2 files changed, 11 insertions(+), 22 deletions(-) diff --git a/api.json b/api.json index 027c102..2a90080 100644 --- a/api.json +++ b/api.json @@ -1343,19 +1343,12 @@ } }, "BlockResponse": { - "description":"A BlockResponse includes a fully-populated block or a partially-populated block with a list of other transactions to fetch (other_transactions).", + "description":"A BlockResponse includes a fully-populated block or a partially-populated block with a list of other transactions to fetch (other_transactions). As a result of the consensus algorithm of some blockchains, blocks can be omitted (i.e. certain block indexes can be skipped). If a query for one of these omitted indexes is made, the response should not include a `Block` object. It is VERY important to note that blocks MUST still form a canonical, connected chain of blocks where each block has a unique index. In other words, the `PartialBlockIdentifier` of a block after an omitted block should reference the last non-omitted block.", "type":"object", - "required": [ - "block_omitted" - ], "properties": { "block": { "$ref":"#/components/schemas/Block" }, - "block_omitted": { - "description":"As a result of the consensus algorithm of some blockchains, blocks can be omitted (i.e. certain block indexes can be skipped). If a query for one of these omitted indexes is made, the response should return `true` for this field. It is VERY important to note that blocks MUST still form a canonical, connected chain of blocks where each block has a unique index. In other words, the `PartialBlockIdentifier` of a block after an omitted block should reference the last non-omitted block.", - "type":"boolean" - }, "other_transactions": { "description":"Some blockchains may require additional transactions to be fetched that weren't returned in the block response (ex: block only returns transaction hashes). For blockchains with a lot of transactions in each block, this can be very useful as consumers can concurrently fetch all transactions returned.", "type":"array", diff --git a/api.yaml b/api.yaml index aaf6608..9bcb7a9 100644 --- a/api.yaml +++ b/api.yaml @@ -700,24 +700,20 @@ components: description: | A BlockResponse includes a fully-populated block or a partially-populated block with a list of other transactions to fetch (other_transactions). + + As a result of the consensus algorithm of some blockchains, blocks + can be omitted (i.e. certain block indexes can be skipped). If a query + for one of these omitted indexes is made, the response should not include + a `Block` object. + + It is VERY important to note that blocks MUST still form a canonical, + connected chain of blocks where each block has a unique index. In other words, + the `PartialBlockIdentifier` of a block after an omitted block should + reference the last non-omitted block. type: object - required: - - block_omitted properties: block: $ref: '#/components/schemas/Block' - block_omitted: - description: | - As a result of the consensus algorithm of some blockchains, blocks - can be omitted (i.e. certain block indexes can be skipped). If a query - for one of these omitted indexes is made, the response should return - `true` for this field. - - It is VERY important to note that blocks MUST still form a canonical, - connected chain of blocks where each block has a unique index. In other words, - the `PartialBlockIdentifier` of a block after an omitted block should - reference the last non-omitted block. - type: boolean other_transactions: description: | Some blockchains may require additional transactions to be fetched