API-Testen

Richtig: PATCH – ändert nur die mitgeschickten Felder

PUT ersetzt die ganze Ressource: Fehlende Felder können dabei geleert werden. PATCH ändert nur, was mitgeschickt wird. Guter Test: per PUT nur die Telefonnummer senden und prüfen, was mit den übrigen Feldern passiert.

Richtig: GET soll nur lesen; Vorschau-Funktionen oder Virenscanner, die Links aufrufen, melden Nutzer unbeabsichtigt ab

GET gilt als „sicher“, also ohne Nebenwirkung. Mailprogramme, Link-Vorschauen und Suchmaschinen rufen solche Links automatisch auf. Ein Klick-Link sollte deshalb erst eine Bestätigungsseite zeigen, die eigentliche Abmeldung läuft per POST.

Richtig: 400 Bad Request (oder 422) mit einer Beschreibung des Fehlers

Fehler, die der Client verursacht, gehören in den 4xx-Bereich. 500 heißt „der Server hat ein Problem“ und löst oft falschen Alarm im Monitoring aus. 200 mit Fehlertext verwirrt jeden Client, der nur den Status prüft. Ein häufiger Befund in API-Tests.

Richtig: 5 Seiten, die letzte mit 15 Einträgen

95 / 20 = 4,75, also 5 Seiten; auf der letzten bleiben 95 − 80 = 15. Gute Pagination-Tests: genau 0, 1, 20, 21 Einträge, die letzte Seite, eine Seite hinter der letzten und eine negative Seitenzahl.

Richtig: {"name": "Anna", "alter": 56}

JSON verlangt doppelte Anführungszeichen für Texte und Schlüssel und erlaubt kein Komma nach dem letzten Element. Was in JavaScript-Code funktioniert, ist deshalb noch kein gültiges JSON. Strenge Parser lehnen die anderen drei ab.

Richtig: JavaScript speichert Zahlen als double und verliert ab 2⁵³ Genauigkeit; große IDs als Text übertragen

In JavaScript sind alle Zahlen double. Ganzzahlen sind nur bis 2⁵³ (9.007.199.254.740.992) exakt. Java-long-IDs liegen schnell darüber. Deshalb liefern viele APIs IDs als String. Testidee: IDs nahe und über 2⁵³ verwenden.

Richtig: Sie prüfen, ob beide Seiten die vereinbarte Schnittstelle einhalten, ohne alles gemeinsam starten zu müssen

Der Aufrufer beschreibt, welche Anfragen er stellt und welche Antworten er erwartet. Der Anbieter prüft in seinem Build, ob er das liefert. So fällt eine Änderung, die den Aufrufer bricht, schon vor dem Deployment auf.

Richtig: Content-Type: application/json

Content-Type beschreibt das Format dessen, was gesendet wird. Accept sagt, was man zurückhaben möchte. Fehlt der richtige Content-Type, lehnen viele Server mit 415 Unsupported Media Type ab. Ein guter Negativtest.

Richtig: Die Ressource hat sich nicht geändert, der Client kann seine zwischengespeicherte Kopie verwenden

Das ETag ist eine Art Fingerabdruck der Ressource. Stimmt er noch, spart der Server die Übertragung. Testidee: Ressource ändern und prüfen, ob sich das ETag ändert. Bleibt es gleich, sehen Clients veraltete Daten.

Richtig: Das Feld "telefon" in "telefonnummer" umbenennen

Umbenennen ist für Clients dasselbe wie Löschen plus Neuanlegen, alte Clients finden "telefon" nicht mehr. Hinzufügen ist meist unkritisch, vorausgesetzt, Clients ignorieren unbekannte Felder. Auch das sollte man testen.

Richtig: 2026-10-26T14:34:00+01:00

ISO 8601 mit Zeitzonenversatz ist eindeutig und maschinenlesbar. Die deutschen und US-Formate sind leicht zu verwechseln (10/11 = 10. November oder 11. Oktober?). Ohne Zeitzone bleibt offen, welche 14:34 gemeint sind.

Richtig: Eine Prüfung des Inhalts, z. B. Name, ID und Aufbau der Antwort

Status 200 heißt nur, dass irgendetwas zurückkam. Ein leerer Kunde, ein falscher Kunde oder eine Fehlermeldung mit Status 200 würden den Test bestehen. Ein API-Test sollte mindestens die wichtigen Felder oder das Schema prüfen.

Richtig: null löscht die Telefonnummer, weglassen lässt sie unverändert

Bei PATCH muss eine API zwischen „nicht ändern“ und „leeren“ unterscheiden. In Java ist das tückisch, weil beim Einlesen beides oft zu null wird. Ein klassischer Testfall, der genau diesen Unterschied prüft.

Richtig: 503 Service Unavailable

503 meldet ein vorübergehendes Problem, ein späterer Versuch kann klappen (am besten mit wachsenden Abständen). Bei 400, 401 oder 404 ist die Anfrage selbst falsch, eine Wiederholung erzeugt nur zusätzliche Last.

Richtig: 204 No Content

204 heißt: erfolgreich, aber nichts zurückzugeben. 200 mit Inhalt geht auch. Interessanter Folgetest: Was liefert ein zweites DELETE auf denselben Kunden? Meist 404, und das sollte dokumentiert sein.

Richtig: Einträge erscheinen doppelt, weil sich alles nach hinten verschiebt

Kommt vorne ein neuer Eintrag hinzu, rutscht der letzte von Seite 1 auf Seite 2 und wird erneut geliefert. Beim Löschen fehlen umgekehrt Einträge. Abhilfe: Cursor-basiertes Blättern („gib mir die nächsten 20 nach Bestellung 4711“).

Richtig: Einen simulierten Dienst (z. B. WireMock) starten, der gezielt Fehler, Verzögerungen und Sonderfälle liefert

Ein simulierter Dienst kann auf Knopfdruck 500, langsame Antworten oder kaputtes JSON liefern. Gerade die Fehlerfälle, die beim echten Dienst selten sind, lassen sich so zuverlässig und wiederholbar testen.

Richtig: Dass die Felder id und name vorhanden sind

required prüft nur das Vorhandensein. "name": "" besteht die Prüfung. Für Mindestlängen braucht es minLength, für das Verbot weiterer Felder additionalProperties: false. Typische Lücke in automatischen API-Prüfungen.

Richtig: Die API begrenzt auf ein festgelegtes Maximum oder lehnt mit 400 ab

Ohne Obergrenze kann ein einziger Aufruf den Server lahmlegen. Ob kappen oder ablehnen, muss festgelegt und dokumentiert sein. Ein Test mit einem sehr großen Wert gehört zu jeder Pagination-Prüfung.

Richtig: M%C3%BCller%20Str

Leerzeichen und Umlaute müssen in URLs prozentkodiert werden. ü wird in UTF-8 zu den Bytes C3 BC, also %C3%BC. %FC wäre die alte Latin-1-Kodierung, die auf dem Server wieder zu kaputten Umlauten führt.