15 — Communication: TCP, UDP, HTTP, and the API Styles

"Just HTTP" was how I flattened system-to-system communication, and it hid the two-layer stack underneath. Writing it down separated the layers: two transport protocols (TCP reliable, UDP fast) carry the bytes, and several API styles (REST, RPC, gRPC) define the conversation on top. [1][4] No system exists in isolation; they all communicate, and the protocol choice is a trade-off between reliability, latency, and coupling.

The framing that landed is to read the choice in two steps. First, pick the transport: do I need every byte to arrive in order (TCP), or do I need the lowest possible latency and can tolerate loss (UDP)? Second, pick the API style: do I expose resources and verbs (REST), procedures (RPC), or typed binary calls (gRPC)? The two decisions are independent, and conflating them is how I used to say "REST vs TCP" as if those were alternatives.

TCP vs UDP: the transport choice

The transport layer is where the reliability/latency trade-off lives [1][2]:

• TCP (Transmission Control Protocol) is connection-oriented, reliable, and ordered. It establishes a connection before transferring data, ensures packets arrive in the correct sequence without errors, and provides retransmission of lost packets plus flow control for congestion [1]. Use it when correctness matters more than the absolute lowest latency — the web, file transfer, email, RPC.
• UDP (User Datagram Protocol) is connectionless. Datagrams are guaranteed only at the datagram level; they might arrive out of order or not at all. UDP does no congestion control. Without TCP's guarantees it is generally more efficient, and it can broadcast to all devices on a subnet (useful for DHCP, where the client has no IP yet) [2]. Use UDP when the lowest latency matters more than perfect reliability, late data is worse than lost data, or you will implement your own error correction — VoIP, video chat, streaming, realtime multiplayer games.

The diagnostic question: is a lost packet a disaster (TCP) or a dropped frame (UDP)?

HTTP: the universal request/response

On top of TCP sits HTTP — a request/response protocol where clients issue requests and servers issue responses [3]. A basic request is a verb (method) plus a resource (endpoint). The common verbs, and their key properties:

Two properties worth internalizing: idempotent means the operation has the same effect whether run once or many times (GET, PUT, DELETE); safe means it does not change server state (only GET). HTTP is stateless and self-contained, so requests and responses can flow through many intermediate routers and proxies that perform load balancing, caching, encryption, and compression [3].

API styles: REST, RPC, gRPC

Given the transport, how do I structure the _conversation_? The roadmap points at three styles, each with a different coupling profile [4][5][6]:

• REST is an architectural style enforcing a client/server model where the client acts on a set of resources managed by the server. Resources are identified by URIs, manipulated through verbs (GET/POST/PUT/DELETE/PATCH), and all communication is stateless and cacheable. REST exposes data and minimizes client/server coupling — it is the default for public HTTP APIs and is great for horizontal scaling because it is stateless [5].
• RPC (Remote Procedure Call) causes a procedure to execute on a different address space, coded as if it were a local call. RPC exposes behaviors — it is focused on actions, not resources. It is often used for performance reasons in internal communications, where hand-crafted native calls fit the use case. The cost: RPC clients become tightly coupled to the service implementation, and a new API must be defined for every operation [4]. Frameworks include Protobuf, Thrift, and Avro.
• gRPC is a high-performance, open-source RPC framework built on Protocol Buffers, supporting many languages [6]. It brings strong typing and binary efficiency to RPC, and is the modern default when internal services need a typed, fast, code-generated contract — the opposite end of the coupling/spectrum from REST's loose resource model.

The trade-off map I keep: REST for public, loosely-coupled, resource-oriented APIs; RPC/gRPC for internal, tightly-coupled, behavior-oriented calls where a typed contract and binary speed matter. GraphQL (covered in the frontend notes) sits as a fourth option when the client needs to declare its own response shape.

How I use this

Two habits. First, I pick the transport by the failure tolerance — TCP for anything where a dropped byte corrupts the result, UDP only for realtime streams where a dropped frame is preferable to waiting. Second, I pick the API style by the audience: REST for external consumers who benefit from a loose, resource-oriented contract; gRPC for internal service-to-service calls where both sides are mine and a typed binary contract pays for itself in speed and safety. The mistake I avoid is using one style for everything — a public REST API and an internal gRPC mesh are not in conflict, they are the right tools for different audiences.

References

[1] D. Martin, "Transmission control protocol (TCP)," system-design-primer (open source), 2024. [Online]. Available: https://github.com/donnemartin/system-design-primer#transmission-control-protocol-tcp

[2] G. On Games, "Networking for game programmers — UDP vs TCP." [Online]. Available: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

[3] cs.fyi, "Everything you need to know about HTTP," 2021. [Online]. Available: https://cs.fyi/guide/http-in-depth

[4] D. Martin, "Remote procedure call (RPC)," system-design-primer (open source), 2024. [Online]. Available: https://github.com/donnemartin/system-design-primer#remote-procedure-call-rpc

[5] D. Martin, "Representational state transfer (REST)," system-design-primer (open source), 2024. [Online]. Available: https://github.com/donnemartin/system-design-primer#representational-state-transfer-rest

[6] Wallarm, "What is gRPC?," 2023. [Online]. Available: https://www.wallarm.com/what/the-concept-of-grpc

[7] "Key differences between TCP and UDP protocols," nixCraft. [Online]. Available: http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/