Have a Reason When You Switch Protocols

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.

We can't prescribe any particular protocol without knowing more about the needs of an enterprise group, but we feel pretty strongly that all API efforts should begin, and consist of a strong base of HTTP APIs, with thoughtful, coherent, and meaningful deviance from HTTP into the world of TCP. We are closely watching what Google is doing with HTTP/2 and HTTP/3. We are being very thoughtful regarding what features we add to our event-driven API architecture, and how we leverage Internet protocols. Resulting in us always having a reason for when we switch protocols, and move from HTTP to TCP, and back again, and being mindful of what our customers and their users are needing when it comes to moving data and content around using the Internet. Helping them be more successful in how they provide access to their digital resources, using existing Internet protocols.