REST, WebSocket, FIX e MT5 são frequentemente apresentados como quatro APIs de forex concorrentes. Eles não são.

REST é geralmente a maneira mais limpa de solicitar dados de conta, carregar histórico ou enviar um comando ocasional. WebSocket mantém uma conexão aberta para que preços e atualizações de pedidos possam chegar à medida que acontecem. FIX é um padrão de mensagens financeiras utilizado para roteamento de pedidos, relatórios de execução e dados de mercado entre sistemas de negociação profissionais. MT5 é uma plataforma de negociação com várias APIs para diferentes trabalhos.

Um corretor pode usar todos os quatro. Um aplicativo móvel pode carregar uma conta através do REST, transmitir preços através do WebSocket, enviar o pedido para o MetaTrader 5 e direcionar a exposição externa para um fornecedor de liquidez através do FIX. Cada interface pertence a uma parte diferente da negociação.

InterfacePadrão de comunicaçãoMelhor ajustePoor fit
REST APICliente envia uma solicitação e recebe uma respostaFluxos de login, contas, símbolos, histórico, relatórios e comandos de baixa frequênciaStreaming de preços contínuos através de polling repetido
WebSocket APICliente e servidor mantêm uma conexão bidirecional abertaCotações ao vivo, profundidade, status de pedidos e eventos de contaConsultas históricas longas e registros administrativos simples
FIX APIDois sistemas de negociação trocam mensagens financeiras padronizadas dentro de uma sessão gerenciadaFluxo de pedidos de corretora para LP, local e institucionalUma API pública simples para um aplicativo móvel de varejo
MT5 APIsVárias interfaces em torno da plataforma MetaTrader 5Administração de corretora, extensões de plataforma, gateways, relatórios e automação de terminaisUm protocolo universal independente do MT5

Como essas APIs se encaixam em um sistema de negociação forex

Eu trato os quatro nomes como diferentes camadas.

REST e WebSocket geralmente ficam perto da aplicação voltada para o trader. O FIX frequentemente está mais profundo na infraestrutura de execução. O MT5 pode ser a plataforma de negociação no meio, mas também pode se conectar a sites, ferramentas internas e locais externos através de suas próprias APIs.

How one forex order moves through the stack

One order. Five steps. From the trader’s app to execution and back.

RESTFIXWebSocket
Trader appBUY 100K EUR/USD
Broker coreORDER #A-18427 / EUR/USD
API gatewayWaiting
Risk enginePending
Trading platform – MT5Ready
Execution routerPending
RESTWaiting for order
Liquidity providerPrice + fill
CRM / automationAccount and client data
Venue / exchangeMarket data and venues
  1. The app sends the order to the broker through REST.
  2. The liquidity provider sends prices to the broker, and WebSocket keeps the app current.
  3. The broker checks the order and passes it to the trading platform.
  4. The execution router sends the order to the liquidity provider through FIX.
  5. The fill returns to the broker, then the app receives the confirmation through WebSocket.

As rotas exatas variam de corretora para corretora. Algumas plataformas expõem comandos de negociação via REST. Outras transportam tanto requisições quanto eventos através de WebSocket ou TCP bruto. Um corretor MT5 pode usar um gateway, uma ponte ou lógica de negociação interna em vez de enviar cada ordem diretamente para um provedor de liquidez.

Assim, um diagrama deve ser interpretado como um padrão de arquitetura, não como uma promessa de que cada corretor processa uma negociação da mesma forma.

O que é uma API REST em negociação forex?

Uma API REST expõe recursos através do HTTP. Um cliente envia uma solicitação para um endpoint, e o servidor retorna uma resposta.

Chamadas típicas se parecem com isso:

  • GET /accounts/417 para carregar uma conta;
  • GET /orders?status=open para recuperar pedidos abertos;
  • GET /candles?symbol=EURUSD&timeframe=1h para solicitar barras históricas;
  • POST /orders para enviar um pedido;
  • DELETE /orders/8921 para solicitar um cancelamento.

Os URLs exatos e os métodos dependem do provedor. A ideia estável é solicitação e resposta. O HTTP em si é um protocolo sem estado, o que significa que cada solicitação pode ser entendida por conta própria. A especificação HTTP define a semântica por trás dos métodos, códigos de status e respostas.

Onde o REST funciona bem

REST é uma escolha prática para dados que mudam apenas quando solicitados:

  • perfis de conta e permissões;
  • instrumentos disponíveis e configurações de contrato;
  • depósitos, retiradas e relatórios;
  • pedidos históricos, negócios e velas;
  • configurações de estratégia;
  • criando ou cancelando pedidos quando a API suporta negociação.

É fácil inspecionar, registrar, armazenar em cache e integrar com a infraestrutura web comum. A maioria das equipes de desenvolvimento já sabe como trabalhar com HTTP e JSON.

Onde o REST começa a apresentar limitações

REST não é intrinsecamente lento. Uma API REST bem construída pode responder rapidamente o suficiente para muitos fluxos de trabalho de negociação. O problema aparece quando o cliente deve fazer a mesma pergunta centenas de vezes:

O EUR/USD mudou?

Meu pedido foi atendido?

Minha margem mudou?

Aquela consulta cria solicitações repetidas, cabeçalhos e trabalho do servidor. Também pode deixar lacunas entre as consultas. Se o aplicativo solicitar um preço uma vez por segundo, ele não sabe o que aconteceu entre essas solicitações.

Eu uso REST para instantâneas e comandos. Não utilizo polling como a fonte primária do estado de trading ao vivo quando existe um fluxo de eventos apropriado.

O que é uma API WebSocket no trading de forex?

O WebSocket cria uma conexão persistente e bidirecional entre um cliente e um servidor. Após o handshake de abertura, qualquer lado pode enviar uma mensagem sem esperar por uma nova solicitação HTTP. Esse comportamento é definido no protocolo WebSocket.

No aplicativo de negociação, o cliente pode assinar EURUSD uma vez. O servidor, então, envia cada atualização de cotação permitida pela conexão aberta. O mesmo fluxo pode transmitir confirmações de ordens, preenchimentos, alterações de saldo e eventos de margem.

Onde o WebSocket funciona bem

Uma API WebSocket de forex é adequada para dados que mudam continuamente:

  • preços de compra e venda;
  • atualizações de gráfico;
  • profundidade de mercado;
  • aceitação, rejeição e preenchimentos de pedidos;
  • mudanças de posição e conta;
  • avisos de margem;
  • status da sessão de negociação.

O cliente recebe mudanças em vez de pedir por elas repetidamente. Isso reduz a sondagem e faz a interface parecer ao vivo.

Uma conexão aberta não é suficiente

O WebSocket não torna um aplicativo de negociação confiável por si só.

Um telefone muda de rede. Um laptop entra em modo de suspensão. Um proxy fecha uma conexão ociosa. O servidor reinicia. As mensagens podem parar de chegar antes que a interface perceba.

Eu procuro cinco mecanismos de recuperação:

  1. Batimento cardíaco. O cliente deve saber se a conexão ainda está ativa.
  2. Estado de dados obsoletos. A interface deve parar de apresentar uma citação antiga como atual.
  3. Reconectar e reinscrever-se. O cliente precisa restaurar todos os fluxos necessários.
  4. Instantâneo mais atualizações. Após reconectar, carregue um instantâneo REST atual antes de aplicar novos eventos.
  5. Sequência ou cursor. Se a API fornecer identificadores de eventos, use-os para detectar lacunas e duplicatas.

O que é uma API FIX em negociação forex?

FIX significa Financial Information eXchange. Ele define mensagens que os sistemas financeiros usam para se comunicar sobre pedidos, execuções, cotações, dados de mercado e sessões.

Um novo pedido, por exemplo, segue um tipo de mensagem compartilhada com campos nomeados para detalhes como instrumento, lado, quantidade, tipo de pedido e ID do pedido do cliente.

FIX é comum entre:

  • corretores e provedores de liquidez;
  • corretores e bolsas ou outros locais;
  • clientes institucionais e corretores;
  • sistemas de gerenciamento de pedidos e sistemas de execução.

Por que as empresas usam FIX

FIX oferece a ambos os lados uma linguagem financeira comum e uma maneira disciplinada de gerenciar a conexão. Não é automaticamente a API mais rápida; o motor, a rede e a configuração da contraparte ainda determinam o desempenho.

Uma sessão FIX rastreia números de sequência de mensagens. Se um lado receber a mensagem 208 após a mensagem 206, ele pode detectar que 207 está faltando e solicitar um reenvio. Batimentos cardíacos e solicitações de teste ajudam ambos os lados a monitorar a sessão.

Isso é importante quando as mensagens representam pedidos e preenchimentos. “A conexão voltou” não é suficiente. Ambos os sistemas precisam concordar sobre quais mensagens foram processadas.

O que o FIX não resolve

FIX não remove o trabalho de integração.

Duas contrapartes ainda precisam concordar sobre:

  • a versão FIX e as mensagens suportadas;
  • campos obrigatórios, opcionais e personalizados;
  • nomes de símbolos e identificadores de instrumentos;
  • tipos de ordem suportados e valores de tempo em vigor;
  • precisão de preço e quantidade;
  • sessões de negociação e janelas de manutenção;
  • redefinições de sequência e regras de reenvio;
  • casos de teste de certificação;
  • segurança de rede e endereços IP permitidos.

Eu nunca aceito “FIX suportado” como uma resposta de integração completa. Eu peço a especificação da contraparte e o plano de certificação. Um padrão com diferentes regras de campo de cada lado ainda precisa de mapeamento e testes.

O que significa “MT5 API”?

MetaTrader 5 é uma plataforma, não um protocolo de API. MetaQuotes lista várias interfaces para corretores, incluindo APIs de Gerente, Gateway, Relatório, Servidor e Web. Cada uma desempenha um papel diferente no ambiente MT5.

API do Gerente

A API do Gerente é para administração e ferramentas de gerenciamento do lado do corretor. Um corretor pode usá-la para construir utilitários internos em torno de contas, grupos, operações de negociação e administração da plataforma.

Este não é o mesmo produto que a chave de API de um trader de varejo. O acesso, licenciamento e operações suportadas pertencem à configuração do MetaTrader do corretor.

API de Gateway

A API Gateway é para conectar o MetaTrader 5 com sistemas de negociação externos e feeds de dados. A MetaQuotes descreve os gateways como plug-ins da plataforma que lidam com a interação com bolsas de valores ou outros sistemas conectados.

Isso está muito mais próximo da conectividade de mercado do que um ponto de extremidade REST voltado para o trader.

Web, Relatório e APIs de Servidor

A MetaQuotes descreve a Web API como uma interface para conectar a plataforma com os recursos e serviços web de um corretor. A Report API estende os relatórios do servidor. A Server API permite que os operadores da plataforma adicionem funções de servidor de negociação e servidor de histórico.

Seus nomes podem parecer autoexplicativos, mas o escopo e a disponibilidade devem ser verificados na licença do corretor e na documentação técnica.

MQL5

MQL5 é a linguagem e o ambiente de programação usados dentro do MetaTrader 5. Traders e desenvolvedores criam Consultores Especializados, indicadores, scripts e serviços que funcionam com o terminal.

É a rota nativa para uma estratégia automatizada que necessita de dados de gráfico, indicadores e funções de negociação dentro do MT5. Não é um protocolo de corretora para provedor de liquidez.

Integração do MetaTrader 5 com Python

O pacote Python oficial MetaTrader5 permite que um programa Python leia dados e envie solicitações de negociação através de um terminal MetaTrader 5. As palavras importantes são através do terminal.

A documentação oficial do Python diz que o pacote se comunica diretamente com o terminal usando comunicação entre processos. Ele não dá a um serviço de nuvem arbitrário uma conexão direta com o servidor MT5 do corretor.

Essa distinção muda a implantação. Uma estratégia em Python precisa de um ambiente de terminal compatível, sessão de conta, monitoramento e um plano para reinicializações de terminal. Não deve ser projetada como se pip install MetaTrader5 criasse uma API de corretora do lado do servidor.

Um pedido pode passar por várias APIs

Suponha que um trader compre 100.000 unidades de EUR/USD no aplicativo móvel de um corretor.

  1. O aplicativo carrega a conta, a especificação do símbolo e permissões através do REST.
  2. Recebe a oferta e o pedido atuais através do WebSocket.
  3. O trader clica em Comprar. O aplicativo envia um comando de pedido com um ID de pedido de cliente exclusivo.
  4. O serviço de risco do corretor verifica margem, limites e status de mercado.
  5. A plataforma de negociação aceita ou rejeita o pedido. Essa plataforma pode ser a MT5.
  6. Dependendo do modelo de execução do corretor, a exposição externa pode ser enviada a um provedor de liquidez através do FIX, um gateway ou outro conector.
  7. Os relatórios de execução retornam através da pilha.
  8. O aplicativo recebe o pedido atualizado, a posição e o saldo através de seu fluxo de eventos.

REST não competiu com FIX nesta sequência. Eles trabalharam em limites diferentes.

O caso de timeout que expõe uma API fraca

A parte difícil de uma API de pedidos não é enviar a solicitação. É saber o que aconteceu quando a resposta desaparece.

Suponha que o aplicativo envie esta instrução:

Comprar EURUSD, clientOrderId = mobile-84721

A solicitação expirou. Existem duas possibilidades:

  • o corretor nunca o recebeu;
  • o corretor aceitou, mas a resposta não chegou ao aplicativo.

Enviar cegamente o mesmo negócio novamente pode criar duas posições.

Um fluxo de trabalho mais seguro é:

  1. Mantenha o mesmo ID do pedido do cliente.
  2. Consultar o estado da ordem autorizada ou aguardar o evento da ordem.
  3. Deixe o servidor rejeitar ou desduplicar um comando repetido com o mesmo ID.
  4. Reconcilie o pedido final e preencha os registros antes de habilitar outra tentativa.

É por isso que pergunto aos fornecedores de API sobre idempotência antes de perguntar sobre a taxa de solicitações de cabeçalho. Um endpoint rápido que pode duplicar uma ação financeira após um tempo limite não é um bom endpoint de negociação.

REST vs WebSocket vs FIX vs MT5 por caso de uso

RequisitoInterface que eu examinaria primeiroRazão
Site do corretor mostrando histórico da contaRESTConsultas simples, autenticação familiar e respostas claras
Lista de observação ao vivo em um aplicativo web ou móvelWebSocketCotações chegam como eventos sem polling constante
Entrada de pedidos de varejo de um aplicativo personalizadoComando REST mais status WebSocketFluidez clara de submissão com reconhecimento ao vivo e atualizações de preenchimento
Conexão do corretor a um provedor de liquidezFIX ou conector certificado do provedorFluxo de trabalho padrão de pedidos e execução entre sistemas de negociação
Administração do corretor em torno do MT5API do MT5 ManagerConstruído para utilitários de gerenciamento do lado da plataforma
Conexão personalizada do MT5 a um localAPI do MT5 Gateway ou uma configuração de ponte/gateway testadaProjetado para conectividade de mercado da plataforma
Consultor Especialista rodando no MT5MQL5Automação nativa do terminal e ambiente de teste
Análise e execução em Python através de um terminal MT5Pacote Python do MetaTrader 5Fornece acesso do Python a dados do terminal e funções de negociação
Conjunto de dados de pesquisa históricaREST ou exportação de dados em massaPaginamento mais fácil, intervalos de datas e recuperação repetível

A tabela é um ponto de partida. A escolha final depende da API real do provedor, limites de taxa, autenticação, tipos de ordem suportados e garantias de serviço.

Perguntas que faço antes de escolher uma API de negociação forex

Dados de mercado

  • O feed é tick-by-tick, conflado ou amostrado?
  • Os carimbos de data/hora de oferta e pedido são gerados na origem ou na entrega?
  • O fluxo inclui números de sequência?
  • Como um cliente recupera dados após uma desconexão?
  • As especificações de símbolos são versionadas quando as configurações do contrato mudam?

Pedidos

  • Existe um ID de pedido de cliente único?
  • Os comandos de criação e cancelamento são idempotentes?
  • O API pode relatar preenchimentos parciais e múltiplos relatórios de execução?
  • Qual registro é autoritário após um tempo limite?
  • Como são representados os pedidos rejeitados, expirados e substituídos?

Operações

  • Quais são os limites de solicitação, assinatura e conexão?
  • Os ambientes de demonstração e ao vivo são comportamentalmente equivalentes?
  • Há uma página de status e um aviso de manutenção programada?
  • Os logs podem ser correlacionados entre cliente, corretora e local de negociação?
  • Como as mudanças disruptivas são versionadas e anunciadas?

Segurança

  • Quais permissões podem ser limitadas por aplicativo ou token?
  • Como as credenciais são rotacionadas e revogadas?
  • São suportadas listas de autorização de IP, TLS e credenciais de produção separadas?
  • Um serviço pode ler dados sem receber permissão para negociar?
  • Toda ação privilegiada é registrada em um log de auditoria?

As respostas me dizem mais do que o rótulo na API. Duas APIs REST podem diferir mais em qualidade prática do que REST e WebSocket.

O que um corretor deve decidir antes da integração

Um projeto de API geralmente se torna difícil quando a responsabilidade é vaga.

Defina esses pontos antes que o desenvolvimento comece:

  1. Sistema de registro. Qual sistema é responsável por pedidos, preenchimentos, saldos e posições?
  2. Ordem do evento. Como são tratados os duplicados, mensagens atrasadas e atualizações fora de ordem?
  3. Recuperação. Qual snapshot é carregado após uma reconexão, e de qual cursor os eventos recomeçam?
  4. Limite de risco. Quais checagens são feitas antes que um pedido chegue à plataforma ou local?
  5. Modelo de símbolo. Quem mapeia nomes, tamanhos de contrato, sessões e precisão de preços?
  6. Rastro de auditoria. Pode apoiar o rastreamento de uma ação do cliente desde o aplicativo até o relatório de execução final?

É aqui que uma decisão de plataforma se torna uma decisão operacional. A infraestrutura de corretagem da Quadcode reúne a plataforma de negociação, aplicativos para clientes, CRM, back office, risco e integrações em um único ambiente. A conectividade REST, streaming, MT5 ou de liquidez necessária deve ainda ser escrita no design da solução e testada em relação aos próprios fluxos de pedidos do corretor.

Resposta final

Use REST para solicitações claras, instantâneas e registros. Use WebSocket quando a aplicação deve receber alterações ao vivo. Use FIX para comunicação de negociação padronizada entre sistemas profissionais. Use a interface MT5 relevante quando o MetaTrader 5 fizer parte da plataforma.

A maioria dos produtos de forex precisa de uma combinação. Após uma falha na rede, uma arquitetura sólida pode responder a três perguntas: O pedido foi recebido? Foi executado? Todos os sistemas conectados agora concordam com o resultado?