Não há desenvolvimento web hoje sem falar das API’s (Application Programming Interface), em específico a API HTTP (Hypertext Transfer Protocol). Mesmo desenvolvedores amadores, que começaram ontem a estudar algum framework javascript da moda, já devem ter ouvido falar a respeito das API‘s. O HTTP é um protocolo que permitiu que a Web, como a conhecemos, nascesse e se ampliasse até o que temos hoje. É um protocolo vivo e que mesmo hoje segue em desenvolvimento, apresentando novas funcionalidades. Mas nos cabe questionar: seria o principal protocolo da internet a melhor solução para toda e qualquer situação de integração entre sistemas?
No começo dos anos 90, com os primeiros passos da internet, surgiu a possibilidade de que a tecnologia aumentasse a produtividade do mundo corporativo. Levar a internet para a dentro da bolsa de valores era uma questão de tempo, e como todos no mercado sabem: tempo é dinheiro. Ao automatizar as transações das bolsas, não somente aumentaria-se o volume e a velocidade dos processos, mas também o próprio acesso ao mercado, seja por instituições ou por pessoas físicas. Mas independentemente de executar as transações das grandes instituições ou das pessoas físicas, era preciso garantir determinados requisitos específicos para trabalhar com o dinheiro.
Assim surge, em 1992, o FIX, Financial Information Exchange, solução de comunicação em tempo real para sistemas de negociação em bolsa (traders). Ao conectar “sender” (um dos lados da transação) e “acceptor” (terceiro confiável), gerava-se através de heartbeats (mensagens sincronizadas que sinalizam que a comunicação está ativa) e de mensagens sequenciais, a possibilidade de se garantir uma comunicação síncrona. O protocolo se tornou o padrão ideal das instituições financeiras (bolsa, corretoras, administradoras…), para as quais frações de segundo são valiosas e tanto a perda de conexão quanto a perda de dados podem custar caro.
O protocolo FIX tem duas camadas: comunicação e aplicação. A camada de comunicação tem por objetivo estabelecer a conexão entre duas instituições que se comunicam por meio do FIX, e assegurar a consistência dos tráfego de dados. A camada de aplicação define as mensagens, e também que o envio seja compreensível aos seus pares. Ao contrário do HTTP, que também usa TCP (um protocolo de conexão da internet) com o protocolo de transporte, o FIX necessita de uma engine (motor de execução do protocolo) capaz de simultaneamente tratar as mensagens da camada de comunicação e garantir a construção das mensagens a serem enviadas na camada de aplicação. Logo, o FIX é um protocolo que dificilmente é implementado do zero em uma linguagem, geralmente são usados engines, como a quickfix, que tratam dos detalhes do protocolo e permitem que o desenvolvedor se preocupe diretamente com a lógica de negócios entre as instituições.
Com isso, o FIX é sempre a melhor escolha para a integração com instituições financeiras?
Não necessariamente. O FIX fornece diversas funcionalidades e uma solução completa de comunicação entre duas instituições. Porém, para integrações simples, como o simples envio para um único serviço de execução, deve se dar espaço para as API’s HTTP. O FIX vale a pena quando a integração com várias instituições distintas é um diferencial, já que permite uma padronização que, acompanhada das funcionalidades extras, pode compensar o “custo de oportunidade” gerado pela simplicidade proporcionada pela implementação de uma requisição HTTP.
Por exemplo, a Bloomberg, referência em software, tecnologia e dados para o mercado, usa uma API fechada que tem dinâmica e comportamento próprios. Portanto, o código da integração não pode ser reaproveitado para a integração com outras instituições. Porém, ao integrar usando a comunicação FIX, é possível adaptar o desenvolvimento para outros players do mercado, garantindo ao cliente uma flexibilidade importante dentro do sistema. E essa mesma lógica também poderia ser estendida a plataformas de outras entidades, como a da ATG, a de corretoras que usam FIX, etc. – ou seja, qualquer plataforma de execução relevante.
Por fim, para empresas e pessoas que desejem desenvolver uma solução, a escolha entre API HTTP e FIX exige planejamento de longo prazo. Se um desenvolvedor busca, por exemplo, resolver um problema dentro de uma gestora – um caso de envio de ordens, por exemplo -, certamente lhe será mais útil usar o protocolo API corrente, pela simplicidade e rapidez que o desafio lhe exige. Agora, se a necessidade envolve a geração de uma solução multibroker, mais versátil, o FIX é a abordagem ideal. A curva de dificuldade e o tempo despendido serão maiores, mas a solução será muito mais robusta e, principalmente, dialogará melhor com o mercado, com potencial amplo e escalável.
Fabiano Martins | Desenvolvedor da Investtools
