Cor, more touchy than Tommy in Goodfellas.

On the point though, I would reject the claim that an API is a way for two programs to communicate. I don’t think that is the best characterisation.

Rather, an API is a way to compose a whole program from parts – with some general-purpose part or platform providing the API, which is then used as part of a more specific program. Any facility the API provides to the program may well run in-process.

I don’t say that an API could never involve IPC – indeed an IPC mechanism could itself have an API, and Windows has various IPC mechanisms that form part of its API (window messages, named pipes, etc.) – but they are not the same things.

An inter-process communication mechanism meanwhile typically involves communication between two discrete programs which are running at the same time on the same machine, although it could technically involve communication between the multiple processes of a single program. This communication may have a protocol, but it need not involve any kind of API.

As Phil Kendall tried to broach, we’d really need to understand whether you are already familiar with exactly what a “process” is in the context of operating systems, to know whether this answer is properly tailored or not.

IPC is the service that allows applications getting bytes across, to send data from one application (process) to another.

An API defines the language, the semantics of the bytes, the communication. And an API is not necessarily cross-process, it focuses on interaction, not on transport.

If we want to talk we can get telephones. These would be IPC technology. If I want you to do something for me I would call you up and say the magic words that would make you do it. The description of that interaction would be an API. Like offer money, flatter, threaten the man or promise I will return the favor.

Or is it that IPC is the physical implementation of API?

No. The physical thing here is electrons bouncing around. API and IPC are both concepts that define how communication should be done. But IPC deals with a special case.

Let’s say we write a line of code. That code wants to move some data. If that data moves within the same process then it’s not IPC. It’s IPC when
it moves to some concurrent thing (another thread that might be on the same core, or another core, or another computer, or another planet).

Regardless of that, shove that data through some interface that defines what that data can be and what you mean when you put it there and you’re using an API. That might be another method, module, service, or alien.

You can use APIs on the same process or a different process. It’s hard to do any communicating without some kind of API. The one we’re using is called English.

It can be argued that these terms have narrower definitions then what I’m using here. But my point was, even giving them their broadest meaning they still mean different things.

Car analogy: API = Instruction manual. Transmission = Inter process communication.

API = Definition what data you need to supply to get information from a service, and what information the service will return back to you.

IPC = A mechanism to transfer any information from one process to another process running on the same computer.

In the rare case that a service runs in a different process on the same machine (not the usual case of an http connection), you would use IPC to transfer the data defined by the API between the two processes.

An API is a term for defining exposed functionality of a service. While an IPC is a very specific case of communication between a service and its caller.

Think of it this way, there is an Object R that can receive a signal 0101 and will return back the signal 1010. This definition of its such behavior is its API.

Now, this definition said nothing about how the signal will be sent and received, I.e. the communication.

Depending on how the user and the object are separated, different modes of communication can be used. User might be physically tapping the object, or, using short range sound waves, or, using long range radio waves, or, deep space gravity waves and what not.

Hence, IPC is one, specific, mode of communication where the calling process is utilizing the API offered by the receiving process. Since both processes are on same computer, they interchange data via a mechanism provided by the host operating system: IPC.

The same processes could be put on different machines, then one might have to use some other protocol like RPC. The basic API stays the same. The service process still has the same functions. But, the way to call those functions has changed.

Allows me a simplistic approach to the meaning.

• API: What do we allow to do with a particular system?

  It encodes rules for systems to share information in a consistent, secure, reliable and procedural mode. Think of them as contracts.

• IPC: How do systems communicate with each other? Or how those contracts will be consumed?

  We are speaking about the “act” of communicating, regardless of what each system does with the “message”.

When we think of IPC, we often think of communication between remote systems and well-known protocols¹, but they don’t need to be remote. The IPCs are still needed even when all the systems run on the same host. Then, the IPC can rely on network protocols, but not necessarily.

For example, we can communicate two systems (writers and readers) by files. The files’ location doesn’t matter. The IPC between readers and writers could be a convention:

• Writers will write in the location I
• Readers will look for new files on I
• Readers will move processed files to the location P
• Readers will add log files to the location L
• Readers will write results in files stored in R
• Tracking will be done by inspecting R
• etc …

All of this can happen on the same host. Writers, readers and file storage.

If the file storage is remote, we would have to agree on which IPC we implement to allow writers and readers to read and write there. If the remote storage has an API (e.g AWS S3) then the IPC is likely to be HTTP, if there’s no API, it’s likely to be another (FTP, WebDav, …)

[Writer] —IPC—> [(API) File Storage (API)] <–IPC— [Reader]

Between systems meant to communicate with each other, there will always be an IPC (implicit or explicit), but not necessarily an API.

Another difference between both is that APIs and IPCs are executed (or happen) at different layers of the OSI model.

^{1:SMTP, FTP, HTTP, TCP, UDP, Sockets, WebSockets, MQTT, etc.}

IPC

There is IPC mechanism like pipes.

In the shell it’s easy as

cat /etc/passwd | cut -d: -f1

Here we are just passing some data from one process to another process. This is IPC in action.
_{At our level, we don’t care how it is implemented internally and what API is used internally to make it work.}

API

But what data the sending process should send and how the receiving process interprets this data is described by the API.

API here is “sender sends user list one record per line with fields delimited by : where first field is username”.
Receiver can extract and print user names because there is API.

The difference is obvious.