By XTRD CTO Serg Gulko

First of all, I don’t want to start yet another holy war of what is good and bad. Everything below is my personal opinion. If, for some reason, you disagree with it — feel free to leave me a comment and I’ll be happy to continue the dialogue.

Our company, XTRD, provides unified FIX API to trade across multiple cryptocurrency exchanges. Since we started our journey, we’ve had a chance to work with many different APIs — REST-only, REST and Web Sockets, sometimes even FIX. Today I want to explain why I think that REST and Web Sockets isn’t the best choice for trading (with some exceptions).

Don’t get me wrong, we also use REST API in our products — this is one of the best possible ways to communicate with remote systems. Whoever used CORBA or SOAP will definitely understand me. Request and response sequences allow you to create many things. But at the same time, request and response have limits. Trading is more asynchronous than many people think. It’s not only about matching buyers with sellers, but it could also be order re-routing around the entire planet.

Taking into account complex processes, trading activities should be performed in an asynchronous fashion — send and switch to another operation — the counterparty will notify you once order changes its’ state. Therefore, the pure REST “request and response” model is not very useful. You either wait for a server response until success (or failure) or start polling (constantly ask for your order status in a loop). I’m confident that 80% of the load on cryptocurrency exchanges that have REST-only API is caused by this polling. No wonder why everything is so slow…

To solve this problem at least somehow, many exchanges started to offer notification mechanisms over Web Sockets. This is a big step forward. Instead of “destroying” exchanges with repeating “what is my order status” requests, we can simply sit and wait. Unfortunately, not all is sunny here. We discovered several things which can easily add more “fun” into trading systems developer’s lives:

• Sometimes notifications through Web Sockets come prior to the initial REST API call being finalized. Why? REST API and Web Sockets are totally different and independent communication channels. This is similar to situation when you picked up a phone to order some food delivery, you just dialed in, took a deep breath to make an order but suddenly someone (delivery guy) knocked into your door. He probably brought what you were about to order but the cause/effect relationship is broken, which is difficult in a programmatic setting.
• Many exchanges do not allow to assign own IDs to outgoing orders. For those who are not trading it might not sound like a big deal. But compare it for a moment with sending packages without a tracking number and with partially obscured recipient addresses. There is only one way to match your order with exchange’s response — wait for the REST API call to complete. So the counterparty is waiting (and blocking resources) while exchange come up with a response. What a waste of resources…

Mixology is good in bars but attempts to use different contexts simultaneously like REST and Web Sockets is bad by design. Luckily, certain exchanges are providing the ability to trade through Web Sockets as well as receive notifications. For example, you can do it on HitBTC (their API is so perfectly designed so I can’t imagine any better) or CEX.IO.

What does this have to with FIX? FIX is a protocol, created to do only several things in a most efficient way — to trade and to transmit financial data. Of course, with some portion of ingenuity, you could customize it to send things like images… It’s like a jet — it can drive and even float with some extent but its main purpose is to fly. Period.

FIX is asynchronous by design, with relatively strict semantics and workflow but it’s the same workflow for almost every financial institution. If you are capable to trade on LMAX or CME, then you can easily connect to Gemini or XTRD (XTRD is not an exchange, but a routing mechanism).

Despite the fact that the XTRD FIX API is running on top of the native and sometimes (… ok, many times) wonky exchanges APIs, we successfully solved the problems mentioned above. Lock-free algorithms, advanced multi-threading, and 12 years of experience plus some black magic — and our customers can enjoy a standard, familiar workflow.

FIX has a higher learning curve comparable to REST or Web Sockets but all depends on what your end goals are.