Most APIs use HTTP as a transport, but there is always 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 simple because Kafka is how you do big data, or Websockets is how you do real-time data–without much more detail.
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 into 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 come 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.