notes.carlosmeyer.com
Back to notes
•
6 min read
API, Protokoll, WebSocket

Einleitung

APIs (Application Programming Interfaces) sind Schnittstellen, über die Softwarekomponenten miteinander interagieren. Sie definieren, welche Funktionen verfügbar sind, welche Daten ein- und ausgehen und wie diese genutzt werden können, ohne die zugrunde liegende Implementierung offenzulegen.

Dabei ist wichtig zu unterscheiden: Eine API beschreibt die Nutzung (was möglich ist), während ein Protokoll wie HTTP oder WebSocket festlegt, wie die Kommunikation technisch abläuft. In vielen Fällen kapselt eine API ein solches Protokoll und stellt eine vereinfachte, entwicklerfreundliche Oberfläche bereit.

Besonders in der Webentwicklung spielen Remote-APIs eine zentrale Rolle, während Programmiersprachen zusätzlich eigene, lokale APIs bereitstellen.

Historischer Bezug

Früher hat man begonnen, Subroutinen-Bibliotheken zu bauen. Dazu gab es ein Dokument von David Wheeler aus dem Jahr 1952, in dem er feststellte, dass die Vorbereitung für eine Subroutinen-Bibliothek aufwendiger ist als ihre eigentliche Programmierung. Außerdem betonte er die Bedeutung der Dokumentation solcher Bibliotheken.

Daraus lässt sich ableiten, dass APIs bis heute ähnliche Eigenschaften haben:

Die Vorbereitung ist wichtig und die Dokumentation ist zentral. Unabhängig davon, wie gut eine API ist, wird sie ohne gute Dokumentation nicht genutzt.

Definition

Eine API kann allgemein als ein Programmteil beschrieben werden, der von einem Softwaresystem anderen Systemen zur Anbindung zur Verfügung gestellt wird. Sie beschreibt auch die möglichen Interaktionen, mit denen sie verwendet werden kann. Deshalb gehört zu einer API eine detaillierte Dokumentation der Schnittstellenfunktionen mit ihren Parametern.

Eine weitere Definition ist: Eine API spezifiziert die Operationen sowie die Ein- und Ausgaben einer Softwarekomponente. Ihr Hauptzweck ist es, Funktionen unabhängig von ihrer Implementierung zu definieren, sodass sich die Implementierung ändern kann, ohne die Nutzer oder andere Softwarekomponenten zu beeinflussen. Das ist wichtig, weil APIs so gestaltet sein sollen, dass sie von außen angesprochen werden können, ohne den bestehenden Code zu verändern.

Arten von APIs

Grundsätzlich sollte man zwischen Programmiersprachen-APIs und Remote-APIs unterscheiden. In der Webentwicklung sind meist Remote-APIs gemeint, also alles, was mit REST, HTTP usw. arbeitet. Gleichzeitig hat jede Programmiersprache auch eigene APIs.

Unterschiede:

Programmiersprachen-APIs sind Funktionen und Klassen, die direkt innerhalb einer Sprache genutzt werden.

Beispiel:

  • In Java: ArrayList, Math, String
  • In JavaScript: fetch(), Array.map(), console.log()

Diese APIs laufen lokal im gleichen Programm.

Remote-APIs dagegen werden über das Netzwerk angesprochen, meist über HTTP.

Beispiel:

  • fetch("https://api.example.com/users") in JavaScript ruft eine externe API auf
  • Backend stellt Endpunkte wie /api/users bereit

Hier findet die Kommunikation zwischen verschiedenen Systemen statt (Client ↔ Server).

APIs und Protokolle

Beide Begriffe tauchen oft im gleichen Kontext auf, beschreiben aber grundlegend verschiedene Dinge.

API – beschreibt was genutzt werden kann: welche Funktionen, Operationen sowie Ein- und Ausgaben eine Software bereitstellt.

Protokoll – beschreibt wie die Kommunikation technisch abläuft: Regeln für den Datenaustausch zwischen Systemen.

Stell dir eine Funktion wie send(message) vor. Die API sagt dir: Diese Funktion existiert, so rufst du sie auf, das passiert dabei. Das Protokoll regelt dahinter: Wie wird die Nachricht in Bytes zerlegt? Wie wird sie übertragen? Wann gilt sie als angekommen?

Als Entwickler arbeitest du immer gegen die API. Das Protokoll läuft im Hintergrund – für dich meist unsichtbar.

Kapseln und Abstrahieren

Eine API kann intern ein Protokoll nutzen oder kapseln. Sie stellt eine abstrakte Schnittstelle bereit, während die eigentliche Kommunikation über das Protokoll abgewickelt wird.

Zwei Beispiele aus dem Java-Umfeld:

  • Java RMI ist eine API für entfernte Methodenaufrufe – intern verwendet sie das Protokoll JRMP.
  • Java Message Service (JMS) ist eine API für Messaging (z. B. Queues) – die tatsächliche Übertragung übernimmt ein JMS-Provider über ein zugrunde liegendes Protokoll.

Wichtig:

  • Eine API kann ein Protokoll kapseln oder darauf aufbauen.
  • Ein Protokoll selbst kapselt keine API – es kennt keine Funktionen, Klassen oder Methoden, nur Kommunikationsregeln.

HTTP als Sonderfall

HTTP ist ein Protokoll, keine API. Wenn man von einer „HTTP API” spricht, ist eigentlich gemeint: Eine API wird über HTTP zugänglich gemacht – als Web-API bzw. Remote-API. Diese besteht aus definierten Endpunkten (URLs), Requests, Responses und klaren Datenstrukturen. HTTP ist dabei nur der Transportmechanismus.

WebSockets

WebSockets sind ein gutes Beispiel dafür, warum man API und Protokoll sauber trennen sollte – weil beides hier klar voneinander unterscheidbar ist.

Das WebSocket-Protokoll beschreibt die technischen Kommunikationsregeln. Die WebSocket-API beschreibt, wie Entwickler diese Kommunikation im Code benutzen.

Was WebSockets sind

Bei normalem HTTP läuft jede Kommunikation nach dem gleichen Muster: Client fragt, Server antwortet, Verbindung ist beendet. WebSockets durchbrechen dieses Muster. Es wird einmal eine Verbindung aufgebaut – und danach können beide Seiten jederzeit Nachrichten senden, ohne auf eine Anfrage der anderen Seite zu warten.

HTTP:       Client → Server → (fertig)
WebSocket:  Client ↔ Server  (dauerhaft offen)

Das nennt man bidirektionale Kommunikation.

Typische Anwendungsfälle sind überall dort, wo Daten schnell oder regelmäßig aktualisiert werden sollen, ohne dass der Client ständig neu fragen muss: Chats, Live-Benachrichtigungen, Multiplayer-Spiele, Kollaborationstools, Börsenkurse, Job-Status-Updates.

Das Protokoll: RFC 6455

Das WebSocket-Protokoll ist in RFC 6455 standardisiert. Es regelt den Verbindungsaufbau, den Handshake, die Übertragung von Nachrichten und das Schließen der Verbindung.

Der Verbindungsaufbau beginnt über HTTP. Der Client sendet einen normalen HTTP-Request mit dem Wunsch, die Verbindung zu „upgraden”:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

Stimmt der Server zu, wird aus der HTTP-Verbindung eine WebSocket-Verbindung. Ab diesem Punkt gilt nicht mehr das Request-Response-Modell von HTTP, sondern das WebSocket-Protokoll.

Die API: Was der Entwickler sieht

Als Entwickler arbeitest du nicht direkt mit Protokoll-Frames oder dem Handshake. Du benutzt die WebSocket-API – im Browser eine JavaScript-Schnittstelle, auf dem Server eine Bibliothek.

Im Browser:

const socket = new WebSocket("ws://localhost:3000")

socket.onopen = () => {
  socket.send("Hallo Server")
}

socket.onmessage = (event) => {
  console.log(event.data)
}

socket.onclose = () => {
  console.log("Verbindung geschlossen")
}

In Node.js auf dem Server:

server.on("connection", (socket) => {
  socket.send("Hallo Client")

  socket.on("message", (message) => {
    console.log(message)
  })
})

In beiden Fällen rufst du Methoden auf und reagierst auf Events. Den Handshake, das Framing und die technische Übertragung nach RFC 6455 übernimmt der Browser bzw. die Bibliothek im Hintergrund.

new WebSocket(), send(), close(), onmessage, onopen – das ist die API. Handshake, Framing, Byteübertragung – das ist das Protokoll.

Zusammenfassung

Die WebSocket-API kapselt das WebSocket-Protokoll. Der Entwickler benutzt eine einfache Schnittstelle; was darunter passiert, ist für ihn unsichtbar – genau wie beim API/Protokoll-Verhältnis im vorherigen Abschnitt.

Die API ist die Bedienoberfläche für Entwickler. Das Protokoll ist die Regelbasis für die tatsächliche Kommunikation.