Closed nkrsic closed 3 years ago
I figured a sane way to stack the symbol specification was to allow the original invocation style to work by default.
Then subsequently overwrite the resource path based on the user's symbol requests:
EDIT: This is a very nice-to-have feature and very useful for Binance, as the original /exchangeInfo route only allowed a massive dump of all symbols and their filter data. I use this to grab one or a few price filters on the go.
EDIT 2: Obviously an efficient usage of the original endpoint would be to load aggregate price filter data into memory but there is no guarantee of price/lot size filters remaining static over time. The great use of this library (to me) is the flexibility. Also wherever possible, the usage of the functions should reflect usage possible in the endpoint, imo. Also very unlikely a user using the method will confuse their usage between no symbol / one symbol / symbol list in any given context, must think of the end user.
I think another "sane" way might be to break up the function prototypes, but idk, it's very concise as is. Let me know what you think.
Hi @nkrsic , thanks a lot for this! I put two minor comments, please have a look and let me know in case you strongly disagree.
Published on 5.2.1
.
Endpoint now allows specification of 'symbol' or 'symbols'.