Decode API responses

[agraebe]

Currently, the API returns encoded strings in multiple places. These need to be decoded in tooling manually and are hard to read. A developer, for instance, couldn't easily verify if a response is correct or not. It makes the development cycle longer as it should be. We could add a layer of abstraction to our endpoints to decode Clarity values by default with additional repr fields.

Here is a list of endpoints that currently expose encoded hex strings in one of the fields:

• https://blockstack.github.io/stacks-blockchain-api/#operation/get_transaction_list
• https://blockstack.github.io/stacks-blockchain-api/#operation/get_mempool_transaction_list
• https://blockstack.github.io/stacks-blockchain-api/#operation/get_transaction_by_id
• https://blockstack.github.io/stacks-blockchain-api/#operation/get_contract_by_id
• https://blockstack.github.io/stacks-blockchain-api/#operation/get_contract_events_by_id
• https://blockstack.github.io/stacks-blockchain-api/#operation/get_contract_data_map_entry
• https://blockstack.github.io/stacks-blockchain-api/#operation/call_read_only_function
• https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_transactions
• https://blockstack.github.io/stacks-blockchain-api/#operation/get_account_info

[zone117x]

My preference would be adding a repr sibling field, and have it there by default without any params required.
For example:

{
  "output": "0xabcf...",
  "output_repr": "(int 3)",
}

[zone117x]

Also note, I don't think we have defined JSON encoding for Clarity values. For example, a Clarity tuple can have an easily human readable string format, while being just as difficult to use programmatically as decoding a hex string.

We could define a JSON Clarity encoding, something like an extension of the json ABI schema but with additional fields for the literal values?

[agraebe]

Ah, nice! The repr field works as well (updated the issue description to cover that). We already use that in some places. Also like the idea of a JSON Clarity encoding!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[zone117x]

I looked through the referenced endpoints and all the non-proxied endpoints appear to have repr properties now.

For the proxied endpoints, the API would have to make a bunch of semi-redundant wrapper endpoints around the /v2/* paths to add repr properties.
For example /v2/contracts/call-read/{contract_address}/{contract_name}/{function_name} would need something like /extended/v2_wrapper/contracts/call-read/{contract_address}/{contract_name}/{function_name}. I don't think that approach is a good idea. It seems like the stacks-node API should implement these changes itself, because the alternatives seem like bandaids.

[agraebe]

would you like to propose this through an issue on their repo and close out the issue in this one?