API Testing heißt, die Schnittstellen zu prüfen, über die Softwaresysteme miteinander sprechen. Dazu gehört mehr als REST: auch GraphQL, Webhooks, SOAP und MCP, jedes Protokoll mit eigenen Regeln, Stärken und Schwächen. Gut entworfene APIs senken außerdem die Zahl der Aufrufe, die KI-Agenten brauchen, und damit direkt Token-Verbrauch und Kosten. API-Architektur ist deshalb nicht nur eine funktionale Frage, sondern auch eine Frage der Qualität.
Das Wichtigste in Kürze
- APIs, die für Agenten optimiert sind, brauchen weniger Anfragen für dieselben Daten. Das senkt den Token-Verbrauch und die Betriebskosten direkt.
- REST ist eine Sammlung von Empfehlungen und kein strenges Protokoll. Teams können von den Konventionen abweichen und tun es auch, ohne gegen einen formalen Standard zu verstoßen.
- Bei MCP schickt der MCP-Server dem LLM zu Beginn einer Sitzung eine Beschreibung seiner Tools und Ressourcen. So erfährt das Modell, welche Aktionen es aufrufen kann.
- Tests auf API-Ebene sind stabiler und schneller als E2E-Tests im Browser. Eine gute Teststrategie legt für jedes Szenario die passende Ebene fest, statt automatisch auf Frontend-Automatisierung zu setzen.
- Wer den Testentwurf für API-Tests schon an der Dokumentation beginnt, etwa an einer Swagger-Spezifikation, bevor es ein Frontend gibt, spart die Wartezeit am Ende des Entwicklungszyklus und vermeidet Leerlauf.
API Testing: die Schicht, die viele Tester noch links liegen lassen
Tester lieben das Frontend. Das Klicken, den Browser, den sichtbaren Ablauf. Dabei bleibt die Schicht darunter oft ungetestet, obwohl das Frontend häufig der instabilste Ort ist, um einen Fehler zu finden. API Testing setzt genau dort an.
Das Backend gibt dir verlässlicheres und schnelleres Feedback. Eine Anfrage geht raus, eine Antwort kommt zurück, und das Ergebnis ist wiederholbar. Frontend-Tests sind oft flaky. Wenn etwas zuverlässig und schnell laufen muss, ist die API-Ebene der richtige Ort.
Sebastian Malyska nennt sich selbst einen Backend-Menschen aus Überzeugung. Muss er einen Frontend-Test bauen, schiebt er die Logik, wo immer es geht, nach unten Richtung API. Nicht nur aus Vorliebe, sondern weil das Backend vorhersehbarere Ergebnisse liefert.
Sein Rat ist einfach: Lass dich nicht vom Hype mitreißen, welches Frontend-Framework gerade gewinnt. Versteh lieber, was hinter den Kulissen passiert. Welche Protokolle transportieren die Daten, und wie reden die Systeme miteinander?
API Testing beginnt beim Protokoll dahinter
“Wir testen die API” ist zu ungenau, um etwas zu taugen. Hinter dem Begriff stecken mehrere Protokollarten, die sich unterschiedlich verhalten. Der Report von Postman über Zehntausende Unternehmen zeigt, welche davon tatsächlich im Einsatz sind.
REST steht ganz oben, Jahr für Jahr. Webhooks legen zu. GraphQL lag in den Daten von 2024 auf Platz zwei und ist seitdem zurückgefallen. Die Spitzengruppe bleibt im Großen und Ganzen stabil: REST, Webhooks, GraphQL und ein paar weitere.
REST ist eine Empfehlung, kein strenges Protokoll. Wenn jemand ein Objekt mit einem GET-Request löscht, ist das erlaubt, auch wenn es gegen die Konvention verstößt. Wahrscheinlich gab es einen Grund dafür. Deswegen reißt man niemandem den Kopf ab.
SOAP ist das Gegenstück. Ein standardisiertes Protokoll, das dort zum Einsatz kommt, wo es auf Genauigkeit ankommt: Geld, Zeit, Anbindung von Drittanbietern. Betrag, Zeitpunkt und Format werden vorab validiert, weil viel auf dem Spiel steht.
GraphQL ist dafür gebaut, Over-Fetching zu verhindern. Statt Objekt A, Objekt B und Objekt C abzurufen und auf Client-Seite zusammenzusetzen, schickst du eine einzige Anfrage, die genau die Daten nennt, die du brauchst. Der Server liefert genau das und nichts darüber hinaus.
Wer diese Unterschiede kennt, kann entscheiden, wohin ein Test gehört. Ohne dieses Wissen ist API Testing ein Ratespiel.
MCP ist der Proxy, der KI-Agenten an echte Daten bringt
MCP ist die Schicht, die Sprachmodelle mit echten Systemen verbindet, damit sie aufhören zu halluzinieren. Der beliebte Vergleich “MCP ist wie USB für Computer” erklärt gar nichts. Treffender ist: MCP ist die Verbindung zu einem externen Gerät, an das das Modell sonst nie herankäme.
Ein Sprachmodell ist eine schlaue Box, aber es bleibt in dieser Box. Um in der echten Welt etwas zu bewirken, muss es mit echten Systemen arbeiten. Und diese Systeme sprechen nach wie vor die alten Protokolle. Also braucht es etwas dazwischen, eine Art Proxy, der auf der einen Seite mit dem LLM spricht und auf der anderen mit den klassischen Protokollen.
Die Kommunikation läuft über Protokolle, die Tester schon kennen. Standard ist JSON-RPC, transportiert über verschiedene darunterliegende Transportschichten.
Die “automatische Erkennung” eines Agenten ist keine Zauberei, sondern ein festgelegter Austausch. Wenn das Modell zum ersten Mal mit einem MCP-Server spricht, schickt der Server Informationen über sich: welche Ressourcen er hat und welche Tools er anbietet. Das Modell merkt sich eher eine kurze Zusammenfassung als alles auf einmal. Danach kann es nachfragen, zum Beispiel, welchen Datentyp ein bestimmtes Tool erwartet.
Diesen Handshake zu verstehen, gehört zum technischen Handwerk. Ein Tester, der nicht erklären kann, wie ein System funktioniert, sollte auch nicht abnicken, dass es funktioniert.
Gutes API-Design spart Tokens und Geld
Eine API, die für Agenten optimiert ist, kostet weniger Tokens als eine, die nur für Menschen gedacht ist. Der Unterschied landet direkt im Budget.
Die meisten Teams entwerfen APIs noch so wie immer: eine Geschäftsidee, zerlegt in Domänen und Subdomänen, dann in Code gegossen. Für Menschen ist das Ergebnis logisch. Eine Bestellung in der Bestellung, dann eine Rechnung, ein Pfad, dem man in einer Oberfläche folgen kann. Für einen Agenten ist diese Struktur nicht effizient.
Nur sehr wenige Unternehmen entwerfen ihre APIs mit Blick auf Agenten, obwohl ihre Entwickler MCP kennen und ihre Tester längst agentische Tools nutzen. Das Optimierungspotenzial liegt in der Architektur, und es beginnt mit einer Frage, die Tester ohnehin stellen können: Wer sind die Stakeholder, und was heißt gute Qualität für sie?
Niemand fragt die KI, ob sie lieber fünf Anfragen schickt oder eine. Die Token-Abrechnung am Monatsende beantwortet das trotzdem. Eine gut entworfene API bedeutet weniger Roundtrips, weniger Kontext zum Mitschleppen und eine kleinere Rechnung. Größere Modelle bringen größere Kontextfenster, und das verleitet dazu, einfach mehr Daten hineinzustopfen. Besseres Design macht das Gegenteil.
Performancetests gelten als altbacken. Richtig gemacht, werfen sie genau die Fragen auf, die sich jetzt lohnen: Wie schaffen wir das mit weniger Ressourcen? Performance zu verbessern heißt nicht, AWS einen Blankoscheck auszustellen und nach mehr Maschinen zu rufen. Der Weg über die Technik ist der mühsame, und er fördert Fehler mit echtem Schweregrad und echten Auswirkungen zutage.
Eine Teststrategie braucht API Testing und E2E-Tests
Die stärkste Teststrategie deckt beide Ebenen ab, entschieden Feature für Feature. Weder volle E2E-Abdeckung noch reine API-Tests sind allein die Lösung.
E2E-Automatisierung gilt oft als Königsdisziplin. Der Reflex, “alles über die Oberfläche zu automatisieren”, ist stark, besonders bei Entwicklern, die das Frontend lieben. Die Zahlen sprechen aber eine klare Sprache: Zweitausend API-Tests schaffen ihre Arbeit in derselben Zeit wie dreihundert Playwright-Szenarien. Es geht dabei nicht darum, wer gewinnt, denn manches muss an der Oberfläche geprüft werden und manches im Backend. Es ist ein Grund, nachzudenken, bevor man automatisch zu E2E-Tests greift.
Die Testpyramide schwingt immer irgendwo mit. Ob die Anteile am Ende wirklich einer Pyramide entsprechen müssen, ist eine andere Frage. Nimm dir das Feature vor, schau es ehrlich an und entscheide, welche Ebene für welche Prüfung am besten passt. Und bring die Entwickler dazu, ihre Unit-Tests zu schreiben.
Selbstheilende Frontend-Szenarien werden besser und könnten UI-Tests gegenüber sich ändernden Websites stabiler machen. Aber auch diese Selbstheilung kostet zusätzliche Rechenleistung und Zeit. Der Zielkonflikt bleibt.
Manches Verhalten gibt es nur im Frontend, und dort muss es getestet werden. Anderes gibt es nur im Backend. Um zu entscheiden, wohin eine Prüfung gehört, musst du beide Schichten verstehen, und diese Entscheidung triffst du am besten gemeinsam mit den Entwicklern.
Wenn du bisher nur das Frontend kennst, fang hier an
Der Schritt Richtung APIs wird dir nicht schaden. Viele Frontend-Entwickler arbeiten längst so, ohne es als neue Fähigkeit zu bezeichnen.
Das Muster ist verbreitet: E2E-Tests laufen zu langsam, also wandern Setup und Teardown in die API. Die Vorbereitung vor dem Test läuft über eine weitere API. Dann öffnet sich der Browser, die Klicks laufen, der Browser schließt sich, und das Aufräumen läuft wieder über die API. Wer weiter ist, macht die Vorbereitung kaum noch über die Oberfläche.
Deine Werkzeuge zeigen dir schon den Weg. Playwright, ein Frontend-Tool, bringt einen eingebauten API-Client mit. Früher musstest du dafür einen eigenen Client installieren und dir etwas zusammenbasteln. Dass die Framework-Autoren API-Zugriff heute als selbstverständlich ansehen, zeigt dir, wohin sich die Disziplin bewegt.
Konkrete nächste Schritte, sobald du REST im Griff hast:
- Lerne, dass REST nicht das einzige Protokoll ist. GraphQL, Webhooks und andere lösen jeweils andere Probleme.
- Nutze Mocking, um Randfälle im Frontend zu testen, ohne auf ein laufendes Backend angewiesen zu sein.
- Lies die API-Dokumentation früh. Eine Workshop-Übung startet mit nichts als einer Swagger-Spezifikation: Das ist dein Server, das ist die einzige Doku, erarbeite den Happy Flow.
Tester haben nicht den Luxus, auf ein fertiges, hübsches Frontend zu warten. Schon während der Entwicklung liest du die Dokumentation, verstehst, was das Backend tut, und fängst an, dagegen zu testen. Ist das Frontend fertig, führst du aus, was du längst gebaut hast. Warten ist Verschwendung, und Verschwendung ist nicht gut.
