Simple example.
symbol: DENTUSDT
startTime: 2021-09-25 05:30 UTC (timestamp: 1632547800000)
endTime: 2021-09-25 06:30 UTC (timestamp: 1632551400000)
request limit: 1000
During this period there were a lot of trades on this pair, thousands of trades.
If there are a lot of trades in the sample period, api returns 1000. As you set request limit to 1000.
So if you try to get trades from api on this period, you will get strange results.
API will return the LAST 1000 trades, not the FIRST 1000 trades in this period, which would be logical.
At the same time, if you will try to do the same request at binance futures API, you will get FIRST 1000 trades on this period.
No sir, this is a bad decision.
For example, how its work on futures api.
If I have a period (‘startTime’, ‘endTime’), but I don’t know how many trades there were.
I’m making a request, get 1000 trades.
But I see that there is a large gap between the date of the last trade and ‘endTime’.
So I will repeat request with params (date of the last trade, ‘endTime’) and get next 1000.
etc …
The solution you suggested not good. In this case I need to iterate over ‘endTime’.
One more example of bad logic for this route.
1 request.
symbol: COTIUSDT
startTime: 2021-11-29 13:58:12 UTC (timestamp: 1638194292000)
endTime: 2021-11-29 14:57:12 UTC (timestamp: 1638197832000)
request limit: 1000
After this request, you will receive 1000 trades.
The time of the first trade will be: 2021-11-29 13:58:12.065
The time of the second trade will be: 2021-11-29 13:59:19.798
And that’s a good response. I got the first 1000 trades in range startTime - endTime.
2 request.
symbol: COTIUSDT
startTime: 2021-11-29 13:59:20 UTC (timestamp: 1638194360000)
endTime: 2021-11-29 14:58:20 UTC (timestamp: 1638197900000)
request limit: 1000
After this request, you will receive 1000 trades.
The time of the first trade will be: 2021-11-29 14:53:05.515
The time of the second trade will be: 2021-11-29 14:58:19.534
And this is a very bad answer. I got the last 1000 trades in range startTime - endTime.
This is a very big problem for testing historical data. Please fix this.