Basically, I was debating in my head how an API and a protocol are different. After thinking about it, I come my newbie conclusions that I believe they are pretty much the same, except that protocols are more like an API that is widely accepted and used. For example, both API's and protocols define criteria and specifications for two or more components to work together. An API defines that criteria for a specific program. A protocol say, such as SSH, is a program itself, with it's own specifications. Another to think about is that a protocol is simply a set of specifications. Any thoughts guys? Sorry if I sound ignorant.

  • 1
    related (possibly a duplicate): What's the difference between the terms “protocol” and “standard”?
    – gnat
    Nov 25 '16 at 18:40
  • 3
    In the sense that a protocol accomplishes something against a specification, yes, it is an application. But so is a cake recipe. Nov 25 '16 at 19:00
  • 1
    Neither a protocol, an API nor a cake recipe are applications. SSH can refer to a protocol and there is an application named SSH. Those are not the same things. Nov 25 '16 at 23:32
  • 1
    so how about TCP/IP protocol? what's the program for it?
    – phuclv
    Nov 26 '16 at 1:43
  • 2
    An API is not an application. Your title and the body of your question do not agree.
    – user207421
    Nov 26 '16 at 2:15

No. A protocol is not an application.

A protocol is a set of rules for systems or components of systems to communicate with each other, exchange information, recover from errors, establishing a semantics.

A protocol can be implemented by hardware, software, people, or a combination of any of them.

Usually, the specified behavior is independent of any particular implementation.

On the other hand an application is a computer program, a piece of software.

A protocol say, such as SSH, is a program itself

In reality that app is called after a protocol. Two things with the same name are not necessarily the same thing. You could write an application that implements the SSH protocol and call it "Buba". The application is not the protocol and vice versa. Different versions of Unix and or Linux can have different implementations of the SSH utility, yet all of them call the program ssh.

Many applications implement the XMPP protocol and they are not named after the protocol.

Also it is possible for a protocol to exist only on a document or published (or unpublished) paper if nobody has implemented it yet. Yet is is still a protocol. Even when no software app, system or API implements it. When a protocol is widely accepted (and widely implemented) it can become a standard (or not).

  • Awesome explanation Tulanis! Thanks for the clarification. Nov 25 '16 at 19:41
  • Hmm, nothing here is wrong , it defines a protocols context fairly well but this fails to explain why an API can't be the same thing. The op is right about the concepts being similar. I believe the main difference is the context that would traditionally be implied. Not exactly a technical difference. Americans call it a can. Brits call it a tin. If this is wrong please edit to clarify why. Nov 25 '16 at 20:42

All APIs are protocols, but not all protocols are APIs. For example, the connection between a keyboard and the motherboard is governed by one or several protocols (PS/2, USB, Bluetooth, etc), but we certainly wouldn't call it an API. An API is a specialized form of protocol that allows two applications, sub-systems, etc (or two copies of the same application) to communicate and possibly control each other.

APIs are also what we refer to when we start talking about libraries, such as OpenGL, Win32, .Net, and so on. The source code that you write in whatever language you use calls API endpoints, which in turn invokes libraries, and eventually the operating system or a specific piece of hardware. The API abstracts the literal machine or network interpretation away from the developer so they can focus on implementing applications rather than worrying about how that feature is implemented in the lower levels. In that sense, APIs are a form of abstraction.

For example, the SOAP API of many enterprise applications allow developers to import the API into the development environment of their choice in order to communicate in a prescribed manner. Once implemented, the client software can speak to the server and cause it to insert data, update data, retrieve data, delete data, and so on, in a method prescribed by the server.

Sometimes, protocols and applications are coincidentally named the same thing, usually as a matter of convenience, or because it was the first of its kind. In your example, the SSH application uses the SSH protocol for communication to a text-based terminal. However, Git also allows the SSH protocol to be used as a form of communication to an upstream repository, but Git is not called SSH.

Here's the difference, though: Git's use of the SSH protocol constitutes an API, while the SSH application's use of the SSH protocol is simply a tunnel to a server, and not an API. Git commands, like "push", "pull", "merge", and so on communicate through the SSH protocol but utilize the Git API. Manipulating the server via SSH requires additional commands that are interpreted by a shell, where the shell acts as the API, and SSH acts as the protocol.


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.