comments/suggestions to GET /v0/token_pairs endpoint

[caleb t]

1. The keys for each token payload (ie. tokenA, tokenB) are not useful or standard if the user is searching for a specific pairing (or token). As the number of possible tokens increases users may not want to traverse the array to find a specific symbol or address.

2. While Radar is planning to support NxN token pairings it is possible not all Relayers will support low volume pairings. The endpoint as it stands serves well for seeing what tokens are available on the Relayer however is not structured to support strict or limited pairings.

[Amir Bandeali]

Perhaps we can add optional query string parameters to this endpoint so that users can check information for specific pairs or tokens.

[caleb t]

if committed to addressing point 2 could consider doing something like the following:

• rename /token_pairs to /tokens. point of this endpoint is to see all tokens available on the Relayer but not the pairs per token. "token_pairs" no longer makes sense in this context.
• create /token_pairs/:tokenAddress which returns an array of token payloads that are paired with tokenAddress.

[Amir Bandeali]

I like this suggestion. As is, there is redundancy in the response if the same token is included in multiple pairs. The tokens endpoint can return information about all tokens (address, symbol, decimals, minAmount, maxAmount, and precision), and the token_pairs endpoint can simply return an array of token address pairs.

[Fabio B]

Redundancy is not always a bad thing. Since we want to support pagination in the future, the only sane way to get rid of the redundancy would be to have multiple endpoints.

First, let's clarify that the only information about the token that should be sent by /token_pairs is token information specific to the Relayer. I know our spec also listed symbol and decimals but this was an oversight and we will remove those. The only information sent will be minAmount, maxAmount and precision. The reason for this is that 0x does not believe that clients should trust Relayers with metadata about a given token. This information should be fetched and cached directly from the blockchain. Relayers can decide to provide this information via their API but this will not be part of the standard relayer API.

Given that the redundant information is not excessive, letting it remain redundant allows us to support pagination effortlessly. In addition, we don't expect this endpoint to be queried at high-frequency (unlike the orders endpoint) so making it super performant was not our main design goal.