0

So, an Application Programming Interface is a way for two or more computer programs to communicate with each other.

An application programming interface (API) is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service to other pieces of software.1 A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation.

Then I found that there is a thing called Inter Process Communication:

In computer science, inter-process communication or interprocess communication (IPC) refers specifically to the mechanisms an operating system provides to allow the processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests.1 Many applications are both clients and servers, as commonly seen in distributed computing.

Now if we have two applications within the same computer that are communicating with each other, is the communication "though an API" or "through an IPC"?

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

Noob_Guy
  • 159
  • 1
  • 2
    Do you understand what a process is in OS terms? – Philip Kendall Sep 11 '22 at 14:56
  • So you are mocking me just because you have high rep and im obviously a beginner, huh? – Noob_Guy Sep 11 '22 at 15:02
  • 13
    No, he's trying to gauge your level of understanding so people can know how to approach writing an answer (how detailed, what to explain, what to gloss over) – Filip Milovanović Sep 11 '22 at 15:10
  • An API is not, generally speaking, a way for two distinct programs (in the usual sense) to communicate (although it can be that too). The Wikipedia article cites a source for that sentence, but the source doesn't actually say that (you can peek the book preview on Amazon, and it actually defines an API in a different way). – Filip Milovanović Sep 11 '22 at 15:12
  • 4
    @Noob_Guy: noone is trying to mock you. Would you mind to answer Philip's question? The API definition above talk about *programs* - the IPC definition about *processes*. Do you have a firm understanding of the differences between those two things? If not, please start [here](https://softwareengineering.stackexchange.com/q/325734/9113) – Doc Brown Sep 12 '22 at 07:30

7 Answers7

4

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.

Steve
  • 6,998
  • 1
  • 14
  • 24
2

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.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
2

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.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
2

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 protocols1, 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.

Laiv
  • 14,283
  • 1
  • 31
  • 69
1

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.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • Ok, so you are confirming that IPC is the physical implementation of API, right? Just one more question, is the method of IPC (sockets, shared memory, message passing, etc.) also defined in API? Or is it something decided solely by the operating system? – Noob_Guy Sep 11 '22 at 16:53
  • @Noob_Guy - IPC is not a exactly a physical impl., but more literally a mechanism, that you can build an inter-process API on top of (though, IPC can also refer to the act of performing such communication). For example, a mechanism is something that allows you to send some bytes over (could be some data, could be an instruction), but the other process *must know* how to interpret those bytes (what kind of data structure it is, what it means, what you're supposed to do with it). An API would define all those things; it's a spec that devs come up with, a contract between two pieces of software. – Filip Milovanović Sep 11 '22 at 18:39
  • @Noob_Guy - the IPC method is decided on by the developers of the application (they'll choose what suits their needs best from what's available/feasible, or, if they are using 3rd-party software with a pre-defined API, they'll conform to that). The operating system just provides a number of different options (mechanisms). – Filip Milovanović Sep 11 '22 at 18:59
  • 2
    Noob_guy, I’m confirming no such thing because it is nonsense. IPC and API are totally different categories of things. API = cookbook, IPC = gas pipe. That kind of different. – gnasher729 Sep 11 '22 at 21:37
1

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.

S.D.
  • 957
  • 6
  • 16
0

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.

gapsf
  • 206
  • 1
  • 6