Begriff

API

Networking Dev-Ops S1

3 Quellen 2 Lernpfade 3 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Eine API (Application Programming Interface) ist der universelle Vermittler zwischen verschiedenen Software-Systemen. Man kann es sich – ganz klassisch – wie einen Kellner in einem Restaurant vorstellen, aber schauen wir uns das Detail genauer an:

Du (der Client) sitzt im Restaurant am Tisch. Du möchtest etwas essen (die Daten), das in der Küche (dem Server) zubereitet wird. Das Problem: Du kannst nicht einfach in die Küche stürmen.

Du kennst dich dort nicht aus (Komplexität).
Du würdest den Köchen im Weg stehen (Effizienz).
Du dürftest dort aus hygienischen Gründen gar nicht sein (Sicherheit).

Hier kommt der Kellner (die API) ins Spiel. Er kommt zu dir an den Tisch und bringt dir die Speisekarte (die Dokumentation). Du darfst nur das bestellen, was auf der Karte steht. Du sagst ihm: "Ich möchte die Nummer 12" (der Request). Der Kellner notiert das, geht in die Küche, gibt die Anweisung an die Köche weiter, wartet auf das Gericht und serviert es dir am Ende fix und fertig (die Response).

Du musst nicht wissen, wie der Herd funktioniert oder wo die Pfannen hängen. Du musst nur wissen, wie man bestellt. Genau so funktioniert Software: Deine Wetter-App weiß nicht, wie man Temperatur misst. Sie fragt einfach die API des Wetterdienstes: "Wie warm ist es in Berlin?" und zeigt die Antwort an.

Merksatz: Eine API ist der definierte Weg, wie zwei Programme miteinander sprechen, ohne dass sie die inneren Geheimnisse des anderen kennen müssen.

Wenn du Tools wie n8n, Zapier oder Make nutzt, bist du im Grunde ein "API-Manager". Du verknüpfst verschiedene Dienste miteinander.

Real-World Example: "Login mit Google"

Das ist eines der häufigsten API-Beispiele im Alltag.

Du öffnest eine neue App, z. B. Spotify.
Spotify möchte wissen, wer du bist, hat aber keine Lust, ein eigenes Passwort-System zu bauen.
Spotify nutzt die Google Identity API.
Wenn du auf "Login mit Google" klickst, schickt Spotify einen Boten (API Call) zu Google: "Hey, der User sagt, er ist Tim. Stimmt das?"
Google prüft dein Passwort (bei sich im sicheren Tresor) und sagt dem Boten: "Ja, das ist Tim. Hier ist sein Ausweis."
Spotify lässt dich rein.

Wichtige Begriffe für Anwender

Endpoint: Das ist der "Schalter", an dem du deine Anfrage abgibst. Das sieht aus wie eine Web-Adresse, z. B. https://api.twitter.com/v2/tweets.
Method: Die Art der Bestellung. Willst du etwas haben (GET), etwas neues abgeben (POST) oder etwas löschen (DELETE)?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Wenn du Tools wie n8n, Zapier oder Make nutzt, bist du im Grunde ein "API-Manager". Du verknüpfst verschiedene Dienste miteinander.
Payload / Body: Das "Paket", das du mitschickst. Wenn du einen neuen Kontakt anlegst, stehen hier Name und E-Mail drin.
API Key: Dein Ausweis. Ohne den ignoriert dich der Kellner.

Hier gehen wir tief in die Mechanik. Eine moderne Web-API (meist RESTful) folgt strengen Regeln des HTTP-Protokolls. Wenn du als Developer oder Automation Engineer arbeitest, musst du verstehen, was "unter der Haube" passiert.

1. Anatomie eines API-Calls

Ein API-Aufruf besteht nicht nur aus "Frage und Antwort". Es ist ein präzises Datenpaket.

Der Header: Das sind die Meta-Informationen. Hier klebt der Briefumschlag zu. Im Header steht z. B. Content-Type: application/json (damit der Server weiß: "Aha, da kommt Text im JSON-Format") und oft der Authorization-Token (dein Schlüssel).
Der Body: Die Nutzlast. Bei einem GET-Request (z. B. "Gib mir alle Kunden") ist der Body meist leer. Bei einem POST-Request ("Erstelle Kunde") steht hier das JSON-Objekt: {"name": "Max", "email": "[email protected]"}.

2. Status Codes: Die Sprache des Servers

Der Server antwortet immer mit einem 3-stelligen Code. Den musst du lesen können:

2xx (Erfolg): 200 OK (Alles gut), 201 Created (Habe den Kunden angelegt).
4xx (Dein Fehler): 400 Bad Request (Du hast Quatsch geschickt), 401 Unauthorized (Schlüssel fehlt), 403 Forbidden (Schlüssel da, aber du darfst das nicht), 404 Not Found (Endpoint falsch).
5xx (Server Fehler): 500 Internal Server Error (Der Server brennt), 502 Bad Gateway (Der Server erreicht die Datenbank nicht).

3. REST vs. GraphQL (Architektur-Kampf)

Die meisten APIs heute sind REST (Representational State Transfer).

Konzept: Es gibt "Ressourcen" (Kunden, Produkte, Bestellungen). Jede hat eine eigene URL.
Problem: "Over-fetching". Du willst nur den Namen des Users, musst aber den Endpoint /users/123 abrufen, der dir alles schickt (Adresse, Schuhgröße, Hobby). Das verschwendet Datenvolumen.

Deshalb nutzen Tech-Giganten wie Facebook, Netflix oder Shopify oft GraphQL.

Konzept: Es gibt nur einen Endpoint. Du schickst eine "Query" (eine Wunschliste) hin: "Ich will von User 123 nur den Namen".
Vorteil: Extrem effizient für Mobile Apps, wo jedes Kilobyte zählt.

4. Rate Limiting & Quotas

APIs sind teuer zu betreiben. Damit niemand den Server "DDOS-t" (kaputt macht), gibt es Limits.

Rate Limit: "Maximal 60 Anfragen pro Minute". (Der Türsteher lässt nur einen pro Sekunde rein).
Quota: "Maximal 10.000 Anfragen im Monat". (Dein Handyvertrag). Wenn du das Limit übertriffst, sendet die API den Code 429 Too Many Requests. Gute Automatisierungs-Scripts (in Python oder n8n) müssen das abfangen ("Sleep" einbauen), sonst stürzen sie ab.

1. Das HAL und HATEOAS Konzept

Die strengsten REST-APIs erfüllen das "Glory of REST" Level 3: HATEOAS (Hypermedia as the Engine of Application State). Das bedeutet, die API liefert nicht nur Nackte Daten. Sie liefert im Output direkt die Links (rel="next", rel="delete") mit, die der Client als nächstes ausführen darf.

{
  "orderId": 44,
  "status": "shipped",
  "links": {
    "cancel": "https://api.shop.com/orders/44/cancel" // Nur da, wenn man noch abbrechen darf!
  }
}

Der Client muss keine URLs hardcoden. Das Backend diktiert dynamisch über das Payload die möglichen Zustandsübergänge des Clients (so wie HTML-Links auf einer Website navigieren).

2. Idempotenz und HTTP Methoden

Eine API muss berechenbar sein. Die Methoden GET, PUT und DELETE gelten bei echten REST APIs als idempotent. Egal, ob du den Request DELETE /kunden/123 ein einziges Mal sendest oder 10.000 Mal hintereinander (weil das Netzwerk hängt und dein Script Retries auslöst) – das Endergebnis im System ist das exakt gleiche: Der Kunde existiert nicht mehr. POST /kunden ist nicht idempotent! Feuerst du das 10 Mal ab, weil das Netzwerk stottert, hast du 10 Klone des Kunden in der Datenbank. Deshalb schickt man bei modernen Systemen oft einen Unique Tracking-Key (Stripe Idempotency-Key Header) mit.

3. RPC (Remote Procedure Call) & gRPC

Nicht alles muss REST (Ressourcen-basiert) sein. Bei RPC-APIs ruft der Client direkt eine Funktion auf dem Server auf, als wäre sie eine lokale Methode, fernab von HTTP-Standards. Google hat dafür gRPC entwickelt. Es nutzt HTTP/2 und protobuf (ein binäres Datenformat). Wo REST-APIs gigantische Mülleimer von menschenlesbarem Text (JSON) durch die Kupferleitung schieben (viel Overhead), schiebt gRPC ultrakompakte binäre Nullen und Einsen extrem schnell zwischen Microservices hin und her.

Quick-Check

Warum kann ich nicht einfach direkt auf die Datenbank von z. B. Google zugreifen, sondern muss die API nutzen?
Sicherheit & Kontrolle. Die API (Kellner) prüft, ob du das darfst. Niemand lässt Fremde direkt in die Küche (Datenbank). Zudem abstrahiert die API die technische Komplexität der Datenbank.
Was ist der Unterschied zwischen einem Request und einer Response?
Request = Die Anfrage vom Client an den Server (inkl. Methode, Header, Body). Response = Die Antwort vom Server (inkl. Status Code und Daten).
Was passiert, wenn du das Rate Limit einer API überschreitest?
Der Server blockiert die Anfrage mit dem Status Code 429 Too Many Requests. Du musst warten, bis dein "Budget" wieder aufgefüllt ist.