How APIs Actually Travel Between Systems

So far, we’ve talked about APIs as a way for systems to communicate. But here’s an important clarification. An API defines what systems say to each other. Network protocols define how those messages travel. Let's discuss about some of the most common ways messages move across the network. Think of APIs as the language. Think of protocols as the roads, vehicles, and traffic rules. Let’s walk through the important ones in simple terms. HTTP – the basic conversation HTTP is the most common way applications talk over the internet. When you open a website or an app loads data, it usually uses HTTP underneath. It’s like sending a letter and waiting for a reply. This works well for: HTTPS – HTTP with a lock HTTPS is the same as HTTP, but secured. Think of it like sending the same letter, but inside a locked envelope. Only the sender and receiver can read it. That’s why HTTPS is used for: From an API point of view, nothing changes in behavior. Only privacy and safety improve. WebSocket – keeping the call open WebSocket is different. Instead of sending a message and closing the connection, it keeps the line open. It’s like a phone call: Messages need to flow both ways where Updates must be instant APIs using WebSockets don’t “ask again and again”.They listen continuously. TCP – slow but reliable delivery TCP is about reliability. Imagine sending fragile items through a courier service that: That’s TCP. Most APIs rely on TCP underneath because: It’s slower than some options, but trustworthy. UDP – fast but no guarantees UDP is the opposite approach. It sends messages quickly, without checking if they arrived. Imagine shouting information across a room: Some people may miss it
But it’s fast UDP is used where speed matters more than perfection: APIs rarely use UDP directly, but systems built on real-time data often do. HTTP/3 (QUIC) – modern and faster roads HTTP/3 is a newer version of HTTP that runs on top of UDP. From the API point of view, this mostly happens behind the scenes. SMTP and FTP – special-purpose messengers Some protocols exist for very specific jobs. They are not general API communication tools, but they still represent structured system-to-system communication. They follow strict rules, just like APIs do. APIs don’t float magically between systems. They travel using protocols like: Documentation tells you: Without this clarity, teams guess. And guessing leads to fragile systems. Why this matters for documentation? When API documentation is good, it answers questions like: Without documentation, developers press buttons randomly, like using a TV remote without knowing what each button does. And that brings us back to the same point again. Good documentation doesn’t just explain APIs. It explains how to communicate safely and correctly. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - One side sends a message
- The other side replies
- Conversation ends - Loading pages
- Fetching data
- Simple request–response communication - Login systems
- Any sensitive data - Both sides stay connected
- Both can speak anytime - Real-time notifications
- Live dashboards - Confirms delivery
- Resends if something is lost
- Keeps things in order - Messages arrive correctly
- Nothing is lost silently - Video calls
- Live streaming
- Online games - Reduce delays
- Recover faster from network issues - Mobile apps
- IoT devices
- Real-time experiences - SMTP is designed for emails.
- FTP is designed for file transfers. - HTTP / HTTPS - Which protocol is used
- What behavior to expect
- Whether communication is instant or delayed
- Whether it’s one-time or continuous - Do I request or do I listen?
- Is this real-time or delayed?
- Is this secure?
- Will I get a response immediately?