Our APIs provide a way to programmatically interact with our platforms, but both platforms offer two different interfaces: on Spot, REST and WebSocket (v1 and v2), and on Futures, both REST and WebSocket APIs are provided as well. Sometimes choosing the most appropriate interface for a specific task can be a difficult decision.
On Spot, while both providing the exact same market data (order books, trading history, etc.) and the exact same account data (account balances, order/trade status, etc.), REST and WebSocket do so in significantly different ways.
REST offers a call/response (question/answer) type interface and provides a snapshot of the current data, while WebSocket offers a live streaming type interface and provides real time updates.
An analogy would be the difference between a photograph and a video, in that upon request a photograph provides a snapshot of the subject but no further updates, while a video provides a real time view of the subject with live streaming updates.
While neither REST nor WebSocket are difficult to implement, it is generally accepted that REST is less complex, which allows development time to be reduced, and any subsequent issues to be resolved more quickly.
REST is based upon standard HTTPS requests which are included in the standard libraries of all modern programming languages (and could easily be coded from scratch if not), whereas WebSocket is based upon a WSS upgrade from HTTPS which usually requires additional third party libraries (such as our recommended WebSocket library for Python).
Our API support pages provide ready to use example code for both REST and WebSocket, hence the choice of interface can be made using more critical criteria rather than ease of implementation.
Depending upon the task at hand, either REST only, or WebSocket only, or more likely a combination of both REST and WebSocket would be the optimal choice.
For tasks that only require occasional market data updates, REST would be the preferred choice. For example, a daily cost averaging bot that only required market data once every 24 hours would have no need for real time streaming market data, hence the REST market data endpoints would be more than suitable.
For tasks that required the most up to date market data available, WebSocket would be the preferred choice. For example, an arbitrage bot would need real time market data from multiple markets so as to take advantage of momentary price discrepancies, hence the WebSocket market data feeds would be the ideal choice.
In most cases (such as the majority of trading bots), a combination of REST and WebSocket would allow for the most effective implementation. For example, a mobile app might require real time market data for its charts, while only needing account data occasionally (when making a trade or a funding transaction, for example), hence using the WebSocket market data feeds alongside the REST order/trade/funding status endpoints would be the most efficient combination.
Our API support team would be happy to discuss your API implementation with you, and make suggestions for the optimal way to use our API based upon your intended usage scenario.