The First Packet
On October 29, 1969, the first message was sent over ARPANET. It was supposed to say "LOGIN" but the system crashed after "LO". That first message - two letters transmitted before a crash - is the entire history of distributed systems in miniature. Something tried to communicate, it partially worked, and then something broke.
ARPANET established the foundational concept that every API builds on: request and response. A host sends a structured message to another host, the other host processes it, and sends back a structured response. This sounds obvious now because we have 50 years of experience. In 1969, it was a genuinely radical idea.
FTP and the First Application Protocol
FTP (File Transfer Protocol) arrived in 1971 as the first proper application-layer protocol. It defined two separate TCP connections - one for commands, one for data - and a vocabulary of commands (USER, PASS, LIST, RETR, STOR) for interacting with a remote file system. If you squint, FTP looks a lot like a REST API: it has resources (files), operations (get, put, list, delete), and authentication. The main differences are syntax and transport mechanics.
FTP introduced two principles that still govern API design. First, separation of control and data - the command channel and data channel serve different purposes. Second, a finite command vocabulary - you cannot make up new FTP commands. The protocol defines the contract, and both sides respect it. Modern API versioning exists because this contract needs to evolve without breaking existing clients.
Sun RPC: The First Remote Procedure Call
Sun Microsystems introduced Sun RPC in 1984 with a mission: make calling a function on a remote machine feel like calling a local function. You write code, the RPC stub handles serialization, network transmission, deserialization, and returns the result. From the calling code, it looks like a regular function call.
Sun RPC used XDR (External Data Representation) for serialization and a port mapper (rpcbind) for service discovery. You defined your service interface in a .x file, ran rpcgen to generate stubs, and suddenly you had a network service that felt like a library. NFS (Network File System), which runs on Sun RPC, still ships with every Unix system.
Sun RPC made remote calls look local. The problem was that remote calls are not local. They fail in ways local calls never do: network partitions, timeouts, partial failures, server crashes mid-call. Hiding the network created an abstraction that leaked catastrophically under load.
The Fallacies These Protocols Exposed
These early protocols collectively surfaced what Peter Deutsch would later call the "Fallacies of Distributed Computing." The network is not reliable. Latency is not zero. Bandwidth is not infinite. The network is not secure. Topology changes. Every protocol since has been a response to these realities.
The request-response model survived all of it because it is the simplest model that works. Send a message, get a reply. Whether it is an HTTP GET request or a Kafka consumer poll, the fundamental shape is the same one ARPANET established 55 years ago.
The Failure Modes That Became API Design Principles
ARPANET's NCP protocol (Network Control Program) assumed connections were reliable. When a link failed, the entire network path broke. TCP/IP replaced NCP in 1983 with a different assumption: the network will fail, and the protocol must route around failures. This philosophical shift - design for failure, not against it - is the single most important principle in distributed systems. Every retry policy, circuit breaker, timeout, and bulkhead pattern in modern API design traces back to what TCP/IP learned from ARPANET's fragility.
FTP's two-connection model (separate channels for control and data) solved a specific problem: the data transfer could be large and slow, but control messages (listing directories, changing paths) needed to be responsive. Mixing them on one connection let a large download block control commands. This insight - separate fast-path control from slow-path data - recurs throughout API design. It appears as the command-query responsibility segregation pattern (CQRS), as webhook delivery on separate processes from web request handling, and as priority queues that fast-path high-priority messages past slower bulk work.
Sun RPC's Legacy in gRPC and GraphQL
Sun RPC introduced three ideas that did not die when CORBA and DCOM failed. First: schema-first design. You write the .x IDL file before writing any implementation code. This contract-first approach is the principle behind OpenAPI, Protocol Buffers, and GraphQL's type system. Second: generated client stubs. You should not write serialization code by hand. The schema is the source of truth; tools generate the boilerplate. gRPC's protoc, OpenAPI generators, and GraphQL codegen tools all follow this model. Third: service discovery. Sun RPC's portmapper was a primitive service registry. Kubernetes' DNS-based service discovery, AWS Cloud Map, and Consul are all solving the same problem: how does a caller find the network location of a callee?
- Design for failure, not against it: assume the network will fail and build protocols that recover gracefully.
- Separate control from data: responsive control channels should not be blocked by slow data transfers.
- Schema first, implementation second: the interface contract should exist before the implementation.
- Generate the boilerplate: client stubs, serialization code, and documentation should be derived from the schema.
- Every RPC framework since Sun RPC has improved on these same four concerns. None has eliminated them.
How These Protocols Shaped Modern API Security
ARPANET had no security model. All traffic was visible to all participants on the network. This was acceptable in 1969 when the network was a research project connecting trusted academic institutions. By the 1980s, as ARPANET expanded and eventually became the internet, the absence of security became catastrophic. Every major internet security mechanism - TLS, SSH, HTTPS, certificate authorities, DNSSEC - was built to retrofit security onto a system designed without it. This is why security cannot be added to an API after the fact. The authentication model, the authorization model, and the trust model must be designed in from the beginning.
FTP's plaintext authentication (username and password sent in clear text) was inherited directly from the ARPANET assumption of trusted participants. SFTP and FTPS were created decades later to add encryption. The lesson repeated itself with HTTP (no encryption) begetting HTTPS, with Telnet (no encryption) begetting SSH, and with SMTP (no encryption) begetting SMTPS. Every protocol that shipped without security and had to be retrofitted paid a decade of transition cost. Design security into your APIs from the start.
The ARPANET project also established the value of open publication. Every protocol decision was documented in a Request for Comments (RFC). The RFC process - anyone can write one, acceptance is by rough consensus among implementers - is why the internet protocol stack is built on open standards rather than proprietary technologies. Compare this to CORBA and DCOM, which were designed by committees behind closed doors and resulted in specifications that required expensive toolkits to implement. Open standards with free reference implementations outcompete proprietary standards in every market where the network effects are large enough.
The Failure Modes That Became API Design Principles
ARPANET's NCP protocol (Network Control Program) assumed connections were reliable. When a link failed, the entire network path broke. TCP/IP replaced NCP in 1983 with a different assumption: the network will fail, and the protocol must route around failures. This philosophical shift - design for failure, not against it - is the single most important principle in distributed systems. Every retry policy, circuit breaker, timeout, and bulkhead pattern in modern API design traces back to what TCP/IP learned from ARPANET's fragility.
FTP's two-connection model (separate channels for control and data) solved a specific problem: the data transfer could be large and slow, but control messages (listing directories, changing paths) needed to be responsive. Mixing them on one connection let a large download block control commands. This insight - separate fast-path control from slow-path data - recurs throughout API design. It appears as the command-query responsibility segregation pattern (CQRS), as webhook delivery on separate processes from web request handling, and as priority queues that fast-path high-priority messages past slower bulk work.
Sun RPC's Legacy in gRPC and GraphQL
Sun RPC introduced three ideas that did not die when CORBA and DCOM failed. First: schema-first design. You write the .x IDL file before writing any implementation code. This contract-first approach is the principle behind OpenAPI, Protocol Buffers, and GraphQL's type system. Second: generated client stubs. You should not write serialization code by hand. The schema is the source of truth; tools generate the boilerplate. gRPC's protoc, OpenAPI generators, and GraphQL codegen tools all follow this model. Third: service discovery. Sun RPC's portmapper was a primitive service registry. Kubernetes' DNS-based service discovery, AWS Cloud Map, and Consul are all solving the same problem: how does a caller find the network location of a callee?
- Design for failure, not against it: assume the network will fail and build protocols that recover gracefully.
- Separate control from data: responsive control channels should not be blocked by slow data transfers.
- Schema first, implementation second: the interface contract should exist before the implementation.
- Generate the boilerplate: client stubs, serialization code, and documentation should be derived from the schema.
- Every RPC framework since Sun RPC has improved on these same four concerns. None has eliminated them.
How These Protocols Shaped Modern API Security
ARPANET had no security model. All traffic was visible to all participants on the network. This was acceptable in 1969 when the network was a research project connecting trusted academic institutions. By the 1980s, as ARPANET expanded and eventually became the internet, the absence of security became catastrophic. Every major internet security mechanism - TLS, SSH, HTTPS, certificate authorities, DNSSEC - was built to retrofit security onto a system designed without it. This is why security cannot be added to an API after the fact. The authentication model, the authorization model, and the trust model must be designed in from the beginning.
FTP's plaintext authentication (username and password sent in clear text) was inherited directly from the ARPANET assumption of trusted participants. SFTP and FTPS were created decades later to add encryption. The lesson repeated itself with HTTP (no encryption) begetting HTTPS, with Telnet (no encryption) begetting SSH, and with SMTP (no encryption) begetting SMTPS. Every protocol that shipped without security and had to be retrofitted paid a decade of transition cost. Design security into your APIs from the start.
The ARPANET project also established the value of open publication. Every protocol decision was documented in a Request for Comments (RFC). The RFC process - anyone can write one, acceptance is by rough consensus among implementers - is why the internet protocol stack is built on open standards rather than proprietary technologies. Compare this to CORBA and DCOM, which were designed by committees behind closed doors and resulted in specifications that required expensive toolkits to implement. Open standards with free reference implementations outcompete proprietary standards in every market where the network effects are large enough.