Most APIs use HTTP as a transport, but there is always a significant number of legacy services, as well as a growing class of more modern API solutions that are also using TCP. There are a number of reasons why we switch protocols, moving off HTTP towards a TCP way of getting things done, with most of the reasons being more about emotions than they are ever about anything technical. When we ask people why they went from HTTP APIs to Kafka or Websockets, we find there is rarely a protocol based response. They did it because they needed things done in real-time, through the existence of specific channels or just simply because Kafka is how you do big data or Websockets is how you do real-time data —without much more detail.
While interrogating API providers about the story behind their decision-making process, we often find there wasn’t much scrutiny of who the consumers are, what was gained by moving to TCP, and what was lost by moving off HTTP. There is little awareness of the work Google has done around gRPC and HTTP/2, or what has happened recently around HTTP/3, formerly known as Quick UDP Internet Connections (QUIC). At Streamdata.io we’ve worked hard to understand the differences between the protocols and have a strong grasp the role that these protocols play as a foundation for APIs, and the importance of having a well thought out strategy when it comes to using the Internet for delivering on the API vision across the enterprise. This understanding is the basis for how we develop event-driven infrastructure here at Streamdata.io, thoughtfully augmenting existing HTTP API infrastructure, while also complementing and contrasting what TCP API infrastructure brings to the table. https://goo.gl/kkjUq4