6

What's the difference between an API and a protocol?

To use a specific example: Is Coinbase's choice to refer to its WebSocket client specification as an "API" appropriate? It seems that many companies in their space followed their naming trend. For example, FTX calls this client specification their WebSocket API. This seems like a misuse of the term "API".

6
  • Not all API are websocket API. For a c++ library, headers form an API for example
    – JayZ
    Commented Aug 2, 2022 at 14:58
  • 1
    stackoverflow.com/a/28613534 Commented Aug 2, 2022 at 15:27
  • A specification of something can in principle specify an API as well (by which I mean the interfaces, as in, different libraries would have to implement the same API to be compliant). But a specification can also be more high-level, e.g. it could prescribe things like exchange data formats of messages and certain high-level rules (an overlying standard or protocol of some sort), where implementations are free to define their own APIs for client code (making clients protocol-independent, in principle). Commented Aug 2, 2022 at 15:52
  • You can write a specification for a salt shaker. Just so long as you're, you know, specific. Commented Aug 2, 2022 at 15:59
  • 3
    The simplest way I can think to disambiguate them; API describes the external surface area of a "thing" I want to communicate with. A protocol describes how to communicate, but not what I will be communicating with. For example, The English Language is my protocol for phoning up to order a Pizza, but the API of the Pizza place is their menu and the employee picking up the phone. Commented Aug 2, 2022 at 17:05

3 Answers 3

5

The c2 wiki distinguishes them like this:

An API provides a library that you must link with to use the services. This tightly binds the client and server together. The API tends invade all code layers and creates massive dependencies between layers. It also tends to be simple to use.

A protocol defines a standard request response layer and a common transport. Nothing other than the standard binds the client and server together. Protocols are more complex to use as they are less direct and take a lot of serializing/deserializing/dispatching type logic.

When I skim the ITCH protocol you linked I don't see it teaching me method names or dictating a language to use. I see it telling me what bits to set and where. That's a protocol.

20
  • 2
    I saw the c2 wiki. Their definition of an API seems to be incorrect/outdated and matches what most call a "client library". And for example, their definition fails in that a typical REST API does not require you to link a library. Even if we assumed this definition is mainstream, neither Coinbase nor FTX examples require linking of a library. Borrowing from more reliable resources, Google, Twilio, Stripe all make good examples of distinguishing their APIs from their client libraries, whereas this c2 wiki conflates the two.
    – Katie
    Commented Aug 2, 2022 at 15:58
  • 4
    @Katie - the problem is that there isn't an authority that can impose a universal definition. These terms might have a relatively consistent informal meaning, but if you want to get precise, you have to consider each term in context in which it appears, and sometimes documents will explicitly state the definition, and that establishes the precise meaning of the term within that document or project. This is not unusual - this happens even in rigorous fields such as mathematics, and certainly in science and engineering. 1/2 Commented Aug 2, 2022 at 16:34
  • 2
    People who built the Internet were thinking in terms of communication protocols, whereas in programming we deal with a set of public procedures (or entities that have procedures) that we can call - the API. What the industry calls REST APIs (which is very different from Roy Fielding's original REST, and really, a misappropriation of the name) is essentially a particular style of doing remote procedure calls. It's not about a library or a remote service, it's about the interface; a client relies on an API directly, so an implementation that doesn't adhere to an API will break the client. 2/2 Commented Aug 2, 2022 at 16:34
  • 1
    I wasn't arguing for blurry lines, just wanted to point out that if you want a precise, rigorous definition, you have to be aware that it will only be applicable, in its full rigorousness, within some context, and that you can't necessarily transplant it to some other context as is - since Katie was mentioning things like "incorrect/outdated" and "mainstream" in the first reply. Commented Aug 2, 2022 at 17:20
  • 1
    @FilipMilovanović You're right, rigorous definitions of these are by no means wide spread. I was aiming to get closer to traditional usage. Now this is just me talking, but I always thought of API's as riding on top of a protocol. When you're writing at the protocol level you're using tools that don't know the protocol. Conforming to it is your job. When you're writing at the API level you're talking to some tool that knows of the API and the protocol it rides on. Doesn't matter if it's a library, framework, or language. But that's just me. What do you think? Incorrect/outdated? Commented Aug 2, 2022 at 18:04
1

In computer science, a protocol pertains specifically to communication. This means you have at least two parties and the protocol defines how each is to behave.

An API is a static definition of the way some resource can be accessed and/or utilized. It is typically call-based where a protocol is message-based.

1

A protocol is a specification, a set of rules a message (and it's response) must follow.

An API is the part of an application that is exposed to the user (whether human or robot, they are mostly indistinguishable by the program). Within the full set of functions that make up a program, the API is the subset of functions that deal specifically with receiving input and deliver output from/to the user.

In fact, even libraries have APIs, not just programs. It's the subset of functions that are "exposed".

In the context of web client-server architecture, the API is the exposed part of the server application. The client side is the user that makes the requests.

The client must send requests following whatever protocol the API demands. To do this, the server developers might create a public library for it. But it's not necessary, an independent user could write his own requesting functions, as long as they follow the protocol they'll work.

In a more general sense, for example, the part of Powershell that handles the CLI's input is part of Poweshell's API. The expected shape of the input itself is the protocol.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.