3

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".

As far as I can tell, both docs above provide specification of a wire protocol for data exchange, e.g. message formats, communication, transport etc., built on top of WebSocket as an application layer. Strictly speaking, it seems more appropriate to refer these as WebSocket-based protocols or WebSocket client specifications. Drawing from a similar example, it seems fine to call the ITCH protocol a protocol, but not "the ITCH API".

But for example if a developer follows Coinbase's client specification, implements a JavaScript client library that includes a WebSocket client that has subroutines or methods for communicating with their services, we could refer to these as a WebSocket client API.

I think the appropriate situation to refer to something as a "WebSocket API" is say when a browser exposes a WebSocket API, since said API implements the WebSocket protocol and provides interfaces for sending and receiving data on a WebSocket connection. Such API becomes something that a browser application can integrate.

Likewise, it feels weird to say a sentence like "This is an unofficial client library that integrates FTX's Websocket API" when it is merely sending JSON messages in specified formats.

Improve this question
5
  • Not all API are websocket API. For a c++ library, headers form an API for example
    – JayZ
    Aug 2 at 14:58
  • 1
    stackoverflow.com/a/28613534
    – Robert Harvey
    Aug 2 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).
    – Filip Milovanović
    Aug 2 at 15:52
  • You can write a specification for a salt shaker. Just so long as you're, you know, specific.
    – candied_orange
    Aug 2 at 15:59
  • 1
    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.
    – Ben Cottrell
    Aug 2 at 17:05

2 Answers 2

Reset to default
4

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.

Improve this answer
19
  • 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
    Aug 2 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
    – Filip Milovanović
    Aug 2 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
    – Filip Milovanović
    Aug 2 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.
    – Filip Milovanović
    Aug 2 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?
    – candied_orange
    Aug 2 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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