make gen

client/api_account.go

@@ -33,21 +33,8 @@ var (
 // AccountAPIService AccountAPI service
 type AccountAPIService service
 
-// AccountBalance Get an array of all AccountBalances for an AccountIdentifier and the
-// BlockIdentifier at which the balance lookup was performed. The BlockIdentifier must always be
-// returned because some consumers of account balance data need to know specifically at which block
-// the balance was calculated to compare balances they compute from operations with the balance
-// returned by the node. It is important to note that making a balance request for an account
-// without populating the SubAccountIdentifier should not result in the balance of all possible
-// SubAccountIdentifiers being returned. Rather, it should result in the balance pertaining to no
-// SubAccountIdentifiers being returned (sometimes called the liquid balance). To get all balances
-// associated with an account, it may be necessary to perform multiple balance requests with unique
-// AccountIdentifiers. It is also possible to perform a historical balance lookup (if the server
-// supports it) by passing in an optional BlockIdentifier.
-func (a *AccountAPIService) AccountBalance(
-	ctx _context.Context,
-	accountBalanceRequest *types.AccountBalanceRequest,
-) (*types.AccountBalanceResponse, *types.Error, error) {
+// AccountBalance Get an array of all AccountBalances for an AccountIdentifier and the BlockIdentifier at which the balance lookup was performed. The BlockIdentifier must always be returned because some consumers of account balance data need to know specifically at which block the balance was calculated to compare balances they compute from operations with the balance returned by the node. It is important to note that making a balance request for an account without populating the SubAccountIdentifier should not result in the balance of all possible SubAccountIdentifiers being returned. Rather, it should result in the balance pertaining to no SubAccountIdentifiers being returned (sometimes called the liquid balance). To get all balances associated with an account, it may be necessary to perform multiple balance requests with unique AccountIdentifiers. It is also possible to perform a historical balance lookup (if the server supports it) by passing in an optional BlockIdentifier.
+func (a *AccountAPIService) AccountBalance(ctx _context.Context, accountBalanceRequest *types.AccountBalanceRequest) (*types.AccountBalanceResponse, *types.Error, error) {
 	var (
 		localVarPostBody interface{}
 	)
@@ -100,23 +87,15 @@ func (a *AccountAPIService) AccountBalance(
 		var v types.AccountBalanceResponse
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 200, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 200, response body %s: %w", string(localVarBody), err)
 		}
 
 		return &v, nil, nil
 	case _nethttp.StatusInternalServerError:
 		var v types.Error
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 500, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 500, response body %s: %w", string(localVarBody), err)
 		}
 
 		return nil, &v, fmt.Errorf("error %+v", v)
@@ -139,21 +118,8 @@ func (a *AccountAPIService) AccountBalance(
 	}
 }
 
-// AccountCoins Get an array of all unspent coins for an AccountIdentifier and the BlockIdentifier
-// at which the lookup was performed. If your implementation does not support coins (i.e. it is for
-// an account-based blockchain), you do not need to implement this endpoint. If you implementation
-// does support coins (i.e. it is fro a UTXO-based blockchain), you MUST also complete the
-// /account/balance endpoint. It is important to note that making a coins request for an account
-// without populating the SubAccountIdentifier should not result in the coins of all possible
-// SubAccountIdentifiers being returned. Rather, it should result in the coins pertaining to no
-// SubAccountIdentifiers being returned. To get all coins associated with an account, it may be
-// necessary to perform multiple coin requests with unique AccountIdentifiers. Optionally, an
-// implementation may choose to support updating an AccountIdentifier's unspent coins based on
-// the contents of the mempool. Note, using this functionality breaks any guarantee of idempotency.
-func (a *AccountAPIService) AccountCoins(
-	ctx _context.Context,
-	accountCoinsRequest *types.AccountCoinsRequest,
-) (*types.AccountCoinsResponse, *types.Error, error) {
+// AccountCoins Get an array of all unspent coins for an AccountIdentifier and the BlockIdentifier at which the lookup was performed. If your implementation does not support coins (i.e. it is for an account-based blockchain), you do not need to implement this endpoint. If you implementation does support coins (i.e. it is fro a UTXO-based blockchain), you MUST also complete the /account/balance endpoint. It is important to note that making a coins request for an account without populating the SubAccountIdentifier should not result in the coins of all possible SubAccountIdentifiers being returned. Rather, it should result in the coins pertaining to no SubAccountIdentifiers being returned. To get all coins associated with an account, it may be necessary to perform multiple coin requests with unique AccountIdentifiers. Optionally, an implementation may choose to support updating an AccountIdentifier's unspent coins based on the contents of the mempool. Note, using this functionality breaks any guarantee of idempotency.
+func (a *AccountAPIService) AccountCoins(ctx _context.Context, accountCoinsRequest *types.AccountCoinsRequest) (*types.AccountCoinsResponse, *types.Error, error) {
 	var (
 		localVarPostBody interface{}
 	)
@@ -206,23 +172,15 @@ func (a *AccountAPIService) AccountCoins(
 		var v types.AccountCoinsResponse
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 200, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 200, response body %s: %w", string(localVarBody), err)
 		}
 
 		return &v, nil, nil
 	case _nethttp.StatusInternalServerError:
 		var v types.Error
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 500, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 500, response body %s: %w", string(localVarBody), err)
 		}
 
 		return nil, &v, fmt.Errorf("error %+v", v)

client/api_block.go

@@ -33,18 +33,8 @@ var (
 // BlockAPIService BlockAPI service
 type BlockAPIService service
 
-// Block Get a block by its Block Identifier. If transactions are returned in the same call to the
-// node as fetching the block, the response should include these transactions in the Block object.
-// If not, an array of Transaction Identifiers should be returned so /block/transaction fetches can
-// be done to get all transaction information. When requesting a block by the hash component of the
-// BlockIdentifier, this request MUST be idempotent: repeated invocations for the same
-// hash-identified block must return the exact same block contents. No such restriction is imposed
-// when requesting a block by height, given that a chain reorg event might cause the specific block
-// at height n to be set to a different one.
-func (a *BlockAPIService) Block(
-	ctx _context.Context,
-	blockRequest *types.BlockRequest,
-) (*types.BlockResponse, *types.Error, error) {
+// Block Get a block by its Block Identifier. If transactions are returned in the same call to the node as fetching the block, the response should include these transactions in the Block object. If not, an array of Transaction Identifiers should be returned so /block/transaction fetches can be done to get all transaction information. When requesting a block by the hash component of the BlockIdentifier, this request MUST be idempotent: repeated invocations for the same hash-identified block must return the exact same block contents. No such restriction is imposed when requesting a block by height, given that a chain reorg event might cause the specific block at height n to be set to a different one.
+func (a *BlockAPIService) Block(ctx _context.Context, blockRequest *types.BlockRequest) (*types.BlockResponse, *types.Error, error) {
 	var (
 		localVarPostBody interface{}
 	)
@@ -97,23 +87,15 @@ func (a *BlockAPIService) Block(
 		var v types.BlockResponse
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 200, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 200, response body %s: %w", string(localVarBody), err)
 		}
 
 		return &v, nil, nil
 	case _nethttp.StatusInternalServerError:
 		var v types.Error
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 500, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 500, response body %s: %w", string(localVarBody), err)
 		}
 
 		return nil, &v, fmt.Errorf("error %+v", v)
@@ -136,24 +118,8 @@ func (a *BlockAPIService) Block(
 	}
 }
 
-// BlockTransaction Get a transaction in a block by its Transaction Identifier. This endpoint should
-// only be used when querying a node for a block does not return all transactions contained within
-// it. All transactions returned by this endpoint must be appended to any transactions returned by
-// the /block method by consumers of this data. Fetching a transaction by hash is considered an
-// Explorer Method (which is classified under the Future Work section). This method can be used to
-// let consumers to paginate results when the  block trasactions count is too big to be returned in
-// a single BlockResponse. Calling this endpoint requires reference to a BlockIdentifier because
-// transaction parsing can change depending on which block contains the transaction. For example, in
-// Bitcoin it is necessary to know which block contains a transaction to determine the destination
-// of fee payments. Without specifying a block identifier, the node would have to infer which block
-// to use (which could change during a re-org). Implementations that require fetching previous
-// transactions to populate the response (ex: Previous UTXOs in Bitcoin) may find it useful to run a
-// cache within the Rosetta server in the /data directory (on a path that does not conflict with the
-// node).
-func (a *BlockAPIService) BlockTransaction(
-	ctx _context.Context,
-	blockTransactionRequest *types.BlockTransactionRequest,
-) (*types.BlockTransactionResponse, *types.Error, error) {
+// BlockTransaction Get a transaction in a block by its Transaction Identifier. This endpoint should only be used when querying a node for a block does not return all transactions contained within it. All transactions returned by this endpoint must be appended to any transactions returned by the /block method by consumers of this data. Fetching a transaction by hash is considered an Explorer Method (which is classified under the Future Work section). This method can be used to let consumers to paginate results when the  block trasactions count is too big to be returned in a single BlockResponse. Calling this endpoint requires reference to a BlockIdentifier because transaction parsing can change depending on which block contains the transaction. For example, in Bitcoin it is necessary to know which block contains a transaction to determine the destination of fee payments. Without specifying a block identifier, the node would have to infer which block to use (which could change during a re-org). Implementations that require fetching previous transactions to populate the response (ex: Previous UTXOs in Bitcoin) may find it useful to run a cache within the Rosetta server in the /data directory (on a path that does not conflict with the node).
+func (a *BlockAPIService) BlockTransaction(ctx _context.Context, blockTransactionRequest *types.BlockTransactionRequest) (*types.BlockTransactionResponse, *types.Error, error) {
 	var (
 		localVarPostBody interface{}
 	)
@@ -206,23 +172,15 @@ func (a *BlockAPIService) BlockTransaction(
 		var v types.BlockTransactionResponse
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 200, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 200, response body %s: %w", string(localVarBody), err)
 		}
 
 		return &v, nil, nil
 	case _nethttp.StatusInternalServerError:
 		var v types.Error
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 500, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 500, response body %s: %w", string(localVarBody), err)
 		}
 
 		return nil, &v, fmt.Errorf("error %+v", v)

client/api_call.go

@@ -33,21 +33,8 @@ var (
 // CallAPIService CallAPI service
 type CallAPIService service
 
-// Call Call invokes an arbitrary, network-specific procedure call with network-specific parameters.
-// The guidance for what this endpoint should or could do is purposely left vague. In Ethereum, this
-// could be used to invoke eth_call to implement an entire Rosetta API interface for some smart
-// contract that is not parsed by the implementation creator (like a DEX). This endpoint could also
-// be used to provide access to data that does not map to any Rosetta models instead of requiring an
-// integrator to use some network-specific SDK and call some network-specific endpoint (like
-// surfacing staking parameters). Call is NOT a replacement for implementing Rosetta API endpoints
-// or mapping network-specific data to Rosetta models. Rather, it enables developers to build
-// additional Rosetta API interfaces for things they care about without introducing complexity into
-// a base-level Rosetta implementation. Simply put, imagine that the average integrator will use
-// layered Rosetta API implementations that each surfaces unique data.
-func (a *CallAPIService) Call(
-	ctx _context.Context,
-	callRequest *types.CallRequest,
-) (*types.CallResponse, *types.Error, error) {
+// Call Call invokes an arbitrary, network-specific procedure call with network-specific parameters. The guidance for what this endpoint should or could do is purposely left vague. In Ethereum, this could be used to invoke eth_call to implement an entire Rosetta API interface for some smart contract that is not parsed by the implementation creator (like a DEX). This endpoint could also be used to provide access to data that does not map to any Rosetta models instead of requiring an integrator to use some network-specific SDK and call some network-specific endpoint (like surfacing staking parameters). Call is NOT a replacement for implementing Rosetta API endpoints or mapping network-specific data to Rosetta models. Rather, it enables developers to build additional Rosetta API interfaces for things they care about without introducing complexity into a base-level Rosetta implementation. Simply put, imagine that the average integrator will use layered Rosetta API implementations that each surfaces unique data.
+func (a *CallAPIService) Call(ctx _context.Context, callRequest *types.CallRequest) (*types.CallResponse, *types.Error, error) {
 	var (
 		localVarPostBody interface{}
 	)
@@ -100,23 +87,15 @@ func (a *CallAPIService) Call(
 		var v types.CallResponse
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 200, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 200, response body %s: %w", string(localVarBody), err)
 		}
 
 		return &v, nil, nil
 	case _nethttp.StatusInternalServerError:
 		var v types.Error
 		err = a.client.decode(&v, localVarBody, localVarHTTPResponse.Header.Get("Content-Type"))
 		if err != nil {
-			return nil, nil, fmt.Errorf(
-				"failed to decode when hit status code 500, response body %s: %w",
-				string(localVarBody),
-				err,
-			)
+			return nil, nil, fmt.Errorf("failed to decode when hit status code 500, response body %s: %w", string(localVarBody), err)
 		}
 
 		return nil, &v, fmt.Errorf("error %+v", v)