In particular, these aren't pagination parameters and by that I mean: they don't affect pagination. These are filter parameters which affect the range of data that should be queried. After the creation of the block_range query parameters:
block_range.from_height filters block range to at least this block height
block_range.to_height filters block range to up to this block height
It makes sense to align these together into query parameters that by their naming convention filter the requested block range:
block_range.from_timestamp filters block range to at least this timestamp (equivalent to previous pagination.after)
block_range.to_timestamp filters block range to up to this timestamp (equivalent to previous pagination.before)
The current query parameters in the Indexer API are a bit awkward and could be made much more consistent with a few changes.
While documenting the Indexer API for some possible Neutron partnerships in https://hadron.notion.site/Indexer-API-a2eabb732292453196332cb2727e53f7 I realized that the query parameters I made to "follow" the regular CosmosSDK API pagination parameters were very inconsistent:
pagination.beforepagination.afterIn particular, these aren't pagination parameters and by that I mean: they don't affect pagination. These are filter parameters which affect the range of data that should be queried. After the creation of the
block_rangequery parameters:block_range.from_heightfilters block range to at least this block heightblock_range.to_heightfilters block range to up to this block heightIt makes sense to align these together into query parameters that by their naming convention filter the requested block range:
block_range.from_timestampfilters block range to at least this timestamp (equivalent to previouspagination.after)block_range.to_timestampfilters block range to up to this timestamp (equivalent to previouspagination.before)