blockfrost / openapi

OpenAPI specification for Blockfrost.io service
https://docs.blockfrost.io
MIT License
22 stars 16 forks source link

Add endpoint to get assets for a provided stake address #60

Closed reliablestaking closed 3 years ago

reliablestaking commented 3 years ago

I currently have a process that will..

  1. Get all addresses for a stake key /accounts/{stake_address}/addresses
  2. Get address info for each address /addresses/{address}
  3. Get asset for each amount that is not "lovelace" /assets/{asset}

This however can result in a lot of calls, it would be nice if there was an endpoint like /accounts/{stake_address}/assets that would return a list of the assets directly.

Thank you for taking this into consideration.

mmahut commented 3 years ago

This makes sense, but we need to do a good job documenting it, mostly:

1) The assets are not on the account itself, but on its addresses (/accounts/{stake_address}/addresses/assets maybe makes sense to stress this out) 2) There is no guarantee it will ever list all the assets. If an user is using a mangled address, it will not show.

reliablestaking commented 3 years ago

Can you elaborate on 2, what do you mean by mangled address?

reliablestaking commented 3 years ago

One other thing, I think /assets/{asset} returns the total of an asset, I'm interested in the amount of said asset the account holds.

mmahut commented 3 years ago

@reliablestaking A mangled addresses is a type of address which is basically a base address, but the staking key part of it is not part of the wallet. For example, I derive spending key from my wallet and add staking key from your wallet and make a base address. The balance stays with me but essentially you control the delegation. All mangled addresses are either pointer or base addresses but not all pointer or base are mangled addresses.

A chain can not differentiate between a normal base address and a mangled base address. Its something that only a wallet can differentiate. So, there is no way to guarantee that the assets associated with an account are really the assets that the account owner holds.

/assets/{asset} returns the total assets of an account (so for example your pending rewards). An account cannot hold directly any tokens. Only addresses can hold tokens.

1000101 commented 3 years ago

Reopened this issue since the feature it's not released yet. If all go as planned we should have the release in an hour. Will keep you posted.

1000101 commented 3 years ago

All systems nominal.

@reliablestaking if you wish, you can test the endpoint (not officially released yet) described here. The endpoint is /accounts/{stake_address}/addresses/assets. Have fun!

btroia commented 3 years ago

All systems nominal.

@reliablestaking if you wish, you can test the endpoint (not officially released yet) described here. The endpoint is /accounts/{stake_address}/addresses/assets. Have fun!

Thanks, this is great! 🎉 Any chance this could be further expanded by including the asset details along with each asset id? This will still require 1 + assets.length api requests in order to retrieve all of the asset information.

1000101 commented 3 years ago

All systems nominal. @reliablestaking if you wish, you can test the endpoint (not officially released yet) described here. The endpoint is /accounts/{stake_address}/addresses/assets. Have fun!

Thanks, this is great! tada Any chance this could be further expanded by including the asset details along with each asset id? This will still require 1 + assets.length api requests in order to retrieve all of the asset information.

Good call! Technically, it's possible, but our philosophy is to keep the data minimal and atomic/modular as much as we can. Even the free plan is so generous that calling each asset shouldn't be an issue (if you need the extra data). Generally, the aim is to fetch data in all use cases under 3 hops. We may improve this in the future, but we'd like to keep it as is at the moment for the sake of speed and simplicity.

btroia commented 3 years ago

Ok, no worries! Looping through the unit values and making additional api requests is easy enough - sounds like we shouldn't worry about hitting any api limits if/when needing to query many assets in a short timeframe 👍

1000101 commented 3 years ago

Ok, no worries! Looping through the unit values and making additional api requests is easy enough - sounds like we shouldn't worry about hitting any api limits if/when needing to query many assets in a short timeframe +1

If it proves to be a problem in the future, we'll figure it out! ;)

reliablestaking commented 3 years ago

Looks great on testnet! Really appreciate you adding this!

1000101 commented 3 years ago

Looks great on testnet! Really appreciate you adding this!

You're welcome!