Schnittstellen & APIs — wie Systeme miteinander reden

Anwendungen bestehen heute aus Schnittstellen. Prüfungsrelevant sind HTTP-Methoden, Statuscodes, die REST-Prinzipien und der Unterschied zu SOAP.

Was eine Schnittstelle leistet

Eine Schnittstelle (API) legt fest, wie ein System angesprochen werden darf — welche Aufrufe es gibt, welche Daten hineingehen und was zurückkommt. Der Aufrufer muss die Innereien nicht kennen: Das ist genau der Nutzen der Kapselung auf Systemebene.

HTTP-Methoden

Methode	Bedeutung	Eigenschaft
`GET`	Daten lesen	sicher, ohne Nebenwirkung, wiederholbar
`POST`	neue Ressource anlegen	verändert Daten
`PUT`	Ressource vollständig ersetzen	idempotent: mehrfach aufgerufen gleiches Ergebnis
`PATCH`	Teiländerung	ändert einzelne Felder
`DELETE`	Ressource löschen	idempotent

Idempotent heißt: Derselbe Aufruf mehrfach ausgeführt ändert das Ergebnis nicht weiter. Wichtig für Wiederholversuche nach Netzfehlern.

Statuscodes lesen

Bereich	Bedeutung	Beispiele
`2xx`	Erfolg	200 OK, 201 Created, 204 No Content
`3xx`	Umleitung	301 dauerhaft, 302 temporär, 304 nicht geändert
`4xx`	Fehler beim Aufrufer	400 fehlerhafte Anfrage, 401 nicht authentisiert, 403 nicht berechtigt, 404 nicht gefunden, 429 zu viele Anfragen
`5xx`	Fehler beim Server	500 interner Fehler, 503 nicht verfügbar

401 gegen 403: 401 heißt „ich weiß nicht, wer du bist" (fehlende oder ungültige Anmeldung), 403 heißt „ich weiß es, aber du darfst nicht". Diese Unterscheidung wird gern gefragt.

REST

REST ist kein Protokoll, sondern ein Architekturstil über HTTP mit klaren Prinzipien:

Ressourcenorientiert: URLs benennen Dinge, keine Aktionen — /kunden/42 statt /getKunde?id=42.
Zustandslos: Jede Anfrage enthält alles Nötige; der Server merkt sich nichts zwischen Aufrufen (das macht Skalierung einfach).
Methoden nach Bedeutung (GET/POST/PUT/PATCH/DELETE).
Repräsentationen: dieselbe Ressource als JSON oder XML.
HATEOAS: Antworten enthalten Links auf mögliche Folgeschritte (in der Praxis selten vollständig umgesetzt).

REST gegen SOAP

	REST	SOAP
Stil	Architekturstil	Protokoll mit festem Standard
Format	meist JSON, auch XML	immer XML (Envelope, Header, Body)
Beschreibung	OpenAPI	WSDL
Stärke	leichtgewichtig, gut für Web/Mobile	formale Verträge, Transaktionen, WS-Security
Typisch	öffentliche Schnittstellen	Behörden, Finanz, Legacy

JSON gegen XML

JSON: Objekte { }, Listen [ ], Schlüssel-Wert-Paare — kompakt, direkt in JavaScript/TypeScript nutzbar.
XML: Tags mit Attributen, streng hierarchisch, Schemata (XSD) prüfen Struktur — gut für formale Vorgaben.

Absicherung von Schnittstellen

API-Key: einfacher Schlüssel — geringer Schutz, meist nur Identifikation.
OAuth 2 / Bearer-Token: Zugriff über zeitlich begrenzte Token.
JWT: signiertes Token mit Ansprüchen (Rollen, Ablauf), wird nicht verschlüsselt — also keine Geheimnisse hineinschreiben.
TLS: Transportverschlüsselung, inzwischen Pflicht.
Ratenbegrenzung: schützt vor Überlast und Durchprobieren.

Typische Prüfungsfallen

401/403 verwechseln — die häufigste Statuscode-Frage.
GET für Änderungen nutzen: verletzt die Semantik und ist nicht idempotent-sicher.
Zustandslosigkeit vergessen: Serverseitige Sessions widersprechen dem REST-Prinzip.
PUT und PATCH gleichsetzen: PUT ersetzt alles, PATCH nur Felder.
Secrets im JWT — Payload ist nur kodiert, nicht verschlüsselt.

Weiter üben

Das Grundlagenwissen steht hier frei — geübt wird in der Lernplattform: über 1.300 Prüfungsfragen mit ausführlicher Erklärung zu jeder Antwort, Fortschritt im eigenen Konto.

Zur Lernplattform Weitere Themen