Un protocollo è un'applicazione?

No. Un protocollo non è un'applicazione.

Un protocollo è un insieme di regole per sistemi o componenti di sistemi che comunicano tra loro, scambiano informazioni, recuperano da errori, stabiliscono una semantica.

Un protocollo può essere implementato da hardware, software, persone o una combinazione di ognuno di essi.

Di solito, il comportamento specificato è indipendente da qualsiasi implementazione particolare.

D'altra parte un'applicazione è un programma per computer, un software.

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

In realtà quell'app viene chiamata dopo un protocollo. Due cose con lo stesso nome non sono necessariamente la stessa cosa. Potresti scrivere un'applicazione che implementa il protocollo SSH e chiamarla "Buba". L'applicazione non è il protocollo e viceversa. Diverse versioni di Unix e / o Linux possono avere diverse implementazioni dell'utilità SSH, ma tutte chiamano il programma ssh.

Molte applicazioni implementano il protocollo XMPP e non prendono il nome dal protocollo.

È anche possibile che un protocollo esista solo su un documento o su un documento pubblicato (o non pubblicato) se nessuno lo ha ancora implementato. Eppure è ancora un protocollo. Anche quando nessuna app software, sistema o API lo implementa. Quando un protocollo è ampiamente accettato (e ampiamente implementato) può diventare uno standard (o meno).

Tutte le API sono protocolli, ma non tutti i protocolli sono API. Ad esempio, la connessione tra una tastiera e la scheda madre è regolata da uno o più protocolli (PS / 2, USB, Bluetooth, ecc.), Ma certamente non la chiameremmo un'API. Un'API è una forma specializzata di protocollo che consente a due applicazioni, sottosistemi, ecc. (O due copie della stessa applicazione) di comunicare e possibilmente controllare a vicenda.

Le API sono anche ciò a cui ci riferiamo quando iniziamo a parlare di librerie, come OpenGL, Win32, .Net e così via. Il codice sorgente che scrivi in qualunque lingua tu usi chiama endpoint API, che a sua volta invoca le librerie e infine il sistema operativo o un determinato componente hardware. L'API astrae la macchina letterale o l'interpretazione di rete dallo sviluppatore in modo che possano concentrarsi sull'implementazione delle applicazioni piuttosto che preoccuparsi di in che modo tale funzionalità viene implementata nei livelli inferiori. In questo senso, le API sono una forma di astrazione.

Ad esempio, l'API SOAP di molte applicazioni aziendali consente agli sviluppatori di importare l'API nell'ambiente di sviluppo di loro scelta al fine di comunicare in modo prescritto. Una volta implementato, il software client può parlare al server e farlo inserire dati, aggiornare dati, recuperare dati, eliminare dati e così via, in un metodo prescritto dal server.

A volte, i protocolli e le applicazioni vengono denominati per coincidenza la stessa cosa, di solito come una questione di convenienza, o perché era il primo del suo genere. Nel tuo esempio, l'applicazione SSH utilizza il protocollo SSH per la comunicazione con un terminale basato su testo. Tuttavia, Git consente anche di utilizzare il protocollo SSH come forma di comunicazione per un repository upstream, ma Git non è chiamato SSH.

Ecco la differenza, tuttavia: l'uso di Git del protocollo SSH costituisce un'API, mentre l'uso dell'applicazione SSH del protocollo SSH è semplicemente un tunnel verso un server e non un'API. Comandi Git, come "push", "pull", "merge" e così via comunicano attraverso il protocollo SSH ma utilizzano l'API Git. La manipolazione del server tramite SSH richiede comandi aggiuntivi interpretati da una shell, in cui la shell funge da API e SSH funge da protocollo.