As nossas APIs fornecem uma forma de interagir programaticamente com as nossas plataformas, mas ambas as plataformas oferecem duas interfaces diferentes: no Spot, REST e WebSocket (v1 e v2), e nos Futuros, ambas as APIs REST e WebSocket também são fornecidas. Por vezes, escolher a interface mais apropriada para uma tarefa específica pode ser uma decisão difícil.
No Spot, embora ambos forneçam os mesmos dados de mercado (livros de ordens, histórico de negociação, etc.) e os mesmos dados de conta (saldos de conta, estado de ordens/negociações, etc.), REST e WebSocket fazem-no de formas significativamente diferentes.
REST oferece uma interface do tipo chamada/resposta (pergunta/resposta) e fornece um instantâneo dos dados atuais, enquanto WebSocket oferece uma interface do tipo transmissão em direto e fornece atualizações em tempo real.
Uma analogia seria a diferença entre uma fotografia e um vídeo, na medida em que, mediante solicitação, uma fotografia fornece um instantâneo do assunto, mas sem mais atualizações, enquanto um vídeo fornece uma visão em tempo real do assunto com atualizações de transmissão em direto.
Embora nem REST nem WebSocket sejam difíceis de implementar, é geralmente aceite que REST é menos complexo, o que permite que o tempo de desenvolvimento seja reduzido e quaisquer problemas subsequentes sejam resolvidos mais rapidamente.
REST baseia-se em pedidos HTTPS padrão que estão incluídos nas bibliotecas padrão de todas as linguagens de programação modernas (e poderiam facilmente ser codificados do zero, se não), enquanto WebSocket se baseia numa atualização WSS de HTTPS que geralmente requer bibliotecas adicionais de terceiros (como a nossa biblioteca WebSocket recomendada para Python).
As nossas páginas de suporte da API fornecem código de exemplo pronto a usar para REST e WebSocket, pelo que a escolha da interface pode ser feita usando critérios mais críticos em vez da facilidade de implementação.
Dependendo da tarefa em questão, a escolha ideal seria apenas REST, apenas WebSocket, ou mais provavelmente uma combinação de REST e WebSocket.
Para tarefas que exigem apenas atualizações ocasionais de dados de mercado, REST seria a escolha preferida. Por exemplo, um bot de custo médio diário que só exigisse dados de mercado uma vez a cada 24 horas não precisaria de dados de mercado em tempo real, portanto, os pontos de extremidade de dados de mercado REST seriam mais do que adequados.
Para tarefas que exigem os dados de mercado mais atualizados disponíveis, WebSocket seria a escolha preferida. Por exemplo, um bot de arbitragem precisaria de dados de mercado em tempo real de vários mercados para aproveitar as discrepâncias momentâneas de preços, portanto, os feeds de dados de mercado WebSocket seriam a escolha ideal.
Na maioria dos casos (como a maioria dos bots de negociação), uma combinação de REST e WebSocket permitiria a implementação mais eficaz. Por exemplo, uma aplicação móvel pode exigir dados de mercado em tempo real para os seus gráficos, enquanto só precisa de dados de conta ocasionalmente (ao fazer uma negociação ou uma transação de financiamento, por exemplo), portanto, usar os feeds de dados de mercado WebSocket juntamente com os pontos de extremidade de estado de ordem/negociação/financiamento REST seria a combinação mais eficiente.
A nossa equipa de suporte da API terá todo o gosto em discutir a sua implementação da API consigo e fazer sugestões sobre a melhor forma de usar a nossa API com base no seu cenário de utilização pretendido.