Was eine API ist

Eine API ist der Weg, auf dem ein Programm ein anderes um etwas bittet. Der Name steht für Application Programming Interface, was wenig verrät. In der Praxis, und im Rest dieses Tutorials, ist eine API ein Server, der Requests mit Daten statt mit Webseiten beantwortet.

Eine Wetter-App auf deinem Handy speichert keine Vorhersagen. Wenn du sie öffnest, schickt sie einen Request an einen Server irgendwo, bekommt ein paar Kilobyte Temperaturen und Windgeschwindigkeiten zurück und zeichnet sie auf den Bildschirm. Der Serverteil ist die API. Die App ist einer ihrer Clients.

Dein erster Request

Füge diese Adresse in die Adressleiste deines Browsers ein und drück Enter:

https://api.testingapis.com/api/Products/1

Du bekommst etwa Folgendes zurück:

{
  "id": 1,
  "title": "Wireless Noise-Cancelling Headphones",
  "price": 249.99,
  "description": "Over-ear headphones with 30hr battery life and active noise cancellation.",
  "category": "electronics",
  "image": "https://picsum.photos/seed/prod1/400/400",
  "rating": { "rate": 4.3, "count": 127 },
  "inStock": true,
  "createdAt": "2025-06-12T10:30:00Z"
}

Dein Browser hat einen Request an einen Server geschickt. Der Server hat Produkt Nummer 1 nachgeschlagen und eine Beschreibung davon zurückgeschickt. Dieser Austausch, ein Request und eine Antwort, ist das, worauf jede Interaktion mit einer API hinausläuft. Der Rest dieses Tutorials dreht sich um die Details dieses Austauschs und darum, wie du prüfst, ob der Server sie richtig macht.

Du kannst den Request auch von dieser Seite aus senden. Der Senden-Button unten macht dasselbe wie eben dein Browser und zeigt den Status der Antwort über dem Body. Diese Buttons begegnen dir in allen Lektionen.

Clients und Server

Das Programm, das den Request schickt, ist der Client. Das Programm, das antwortet, ist der Server. Ein Client kann ein Browser sein, eine Handy-App, ein anderer Server, ein Kommandozeilenwerkzeug oder ein Test, den du geschrieben hast. Der Server kann sie nicht unterscheiden und muss es auch nicht. Er liest den Request, erledigt seine Arbeit und antwortet.

Das ist fürs Testen wichtig. Weil der Server jeden Client gleich behandelt, kannst du ihn ohne die App testen, die normalerweise mit ihm spricht. Du musst dich nicht durch fünf Bildschirme einer Shopping-App klicken, um zu sehen, ob der Produktpreis stimmt. Du fragst die API nach dem Produkt und schaust dir den Preis an.

Endpunkte

Die Adresse, die du geöffnet hast, besteht aus zwei Teilen. https://api.testingapis.com ist die Basis-URL: Sie sagt, mit welchem Server gesprochen wird. /api/Products/1 ist der Pfad: Er sagt, was du von diesem Server willst. Jeden Pfad, den der Server versteht, nennt man einen Endpunkt. Diese API hat ein paar Hundert. Einige Beispiele:

Welche Endpunkte es gibt, erfährst du aus der Dokumentation der API. Für diese API ist das die API-Referenz. Echte Projekte sind hier sehr unterschiedlich. Manche haben sorgfältige Dokumentation, manche eine aus dem Code erzeugte OpenAPI-Datei und manche eine Nachricht im Chat von dem Entwickler, der sie geschrieben hat. Ein Teil der Arbeit beim Testen ist, zu bemerken, wenn Dokumentation und API nicht übereinstimmen.

Wenn die Antwort Nein lautet

Frag jetzt nach einem Produkt, das es nicht gibt:

Der Server antwortet:

{
  "status": 404,
  "error": "Not Found",
  "message": "Product with ID 9999 does not exist."
}

Auch das ist eine korrekte Antwort. Es gibt kein Produkt 9999, und der Server sagt das deutlich: ein Status 404, der "nicht gefunden" bedeutet, und eine Nachricht, welche ID gefehlt hat. Eine gute API geht mit den Requests, die sie nicht erfüllen kann, genauso sorgfältig um wie mit denen, die sie erfüllen kann. Viel API-Testing passiert hier, im Fehlerfall, weil Entwickler dort am wenigsten Zeit verbringen und dort die meisten Bugs stecken.

Warum auf API-Ebene testen

Du könntest alles über die Bildschirme der App testen. Teams testen APIs aus einigen praktischen Gründen direkt.

• Es ist schneller. Ein Request dauert Millisekunden. Sich durch eine Oberfläche bis zum selben Zustand zu klicken dauert Sekunden, und diese Klicks zu automatisieren kostet viel mehr Zeit und geht kaputt, sobald ein Button verschoben wird.
• Die API gibt es meist zuerst. Backend und Frontend entstehen oft parallel, du kannst das Backend also testen, bevor es irgendetwas zum Anklicken gibt.
• Die Oberfläche versteckt Probleme. Angenommen, das Mengenfeld einer Shopping-App erlaubt nur Zahlen von 1 bis 10. Die API dahinter bekommt einen ganz normalen Request, und jeder kann einen mit der Menge -5 schicken. Verlässt sich der Server darauf, dass die App geprüft hat, geht die Bestellung mit einer negativen Summe durch. Das findest du nur, wenn du direkt mit der API sprichst.
• Eine API bedient oft mehrere Clients: eine Website, eine iPhone-App, eine Android-App, eine Partner-Integration. Ein Bug in der API ist ein Bug in allen.

UI-Tests haben trotzdem ihren Platz. Nur mit ihnen prüfst du, ob die Bildschirme funktionieren. Aber die Regeln des Systems (wer was sehen darf, wie eine gültige Bestellung aussieht, was passiert, wenn der Bestand ausgeht) leben in der API, also prüfst du sie dort.