So nutzen Sie diese Liste öffentlicher APIs

Wählen Sie eine API und eine Fähigkeit. Schreiben Sie drei Fälle: den Happy Path, einen Grenzfall und einen Fall, in dem Sie einen Fehler erwarten und prüfen, dass dieser Fehler die richtige Form hat. Den dritten lassen die meisten weg – und genau er entscheidet darüber, ob eine Suite Bugs findet oder nur bestätigt, dass der Dienst online ist.

Ein Hinweis vorab: Das sind gemeinsam genutzte Dienste, die von Freiwilligen oder von Unternehmen als Entgegenkommen betrieben werden. Halten Sie Ihr Anfragevolumen niedrig, richten Sie keinen Lastgenerator darauf und cachen Sie Antworten, wo es geht.

Für die Grundlagen von Request und Response

  • JSONPlaceholder. Eine Fake-REST-API mit Posts, Kommentaren, Benutzern und Todos. Sie nimmt Schreibzugriffe entgegen und tut so, als würde sie sie speichern. Üben Sie: CRUD-Verben, Statuscodes und den Unterschied zwischen einem Request, der erfolgreich war, und einer Änderung, die tatsächlich gespeichert wurde. Dass Schreibzugriffe nicht wirklich gespeichert werden, macht diese API zu einer ungewöhnlich guten Lektion darin, auf Ergebnisse statt auf Responses zu prüfen.

  • HTTPBin. Ein Endpunkt, der alles zurückspiegelt, was Sie senden, dazu Routen, die jeden gewünschten Statuscode liefern, absichtlich verzögern oder fehlerhafte Payloads zurückgeben. Üben Sie: Timeouts, Retries, Redirect-Handling und Header-Verhalten. Wenn Sie sehen wollen, wie Ihre Suite auf einen 503 reagiert, erzeugen Sie ihn einfach auf Abruf.

  • REST Countries. Länderdaten mit stabiler, gut dokumentierter Struktur und ohne nötigen Schlüssel. Üben Sie: Schema-Assertions und Validierung auf Feldebene an einem Payload, das groß genug ist, um interessant zu sein, und klein genug, um es noch zu lesen.

Für Pagination und große Collections

PokéAPI

  • Ein großer, tief verlinkter Datenbestand mit klassischer Pagination über offset und limit.

  • Üben Sie: Seiten durchlaufen, prüfen, dass ein vollständiger Durchlauf genau die Anzahl liefert, die die Collection angibt, und Off-by-one-Fehler an den Seitengrenzen aufspüren.

Open Library

  • Buch- und Autorendatensätze mit Suche und reichlich Datensätzen mit fehlenden oder inkonsistenten Feldern.

  • Üben Sie: Toleranz gegenüber optionalen Feldern. Echte Daten sind unsauber, und eine Suite, die jeden Datensatz für vollständig hält, bricht beim ersten Kontakt mit der Produktion.

GitHub REST API

  • Funktioniert bei geringem Volumen ohne Authentifizierung und mit einem Token authentifiziert.

  • Üben Sie: Pagination über Link-Header, Conditional Requests und den Verhaltensunterschied vor und nach der Authentifizierung.

Für Authentifizierung und Rate Limits

GitHub, authentifiziert

  • Üben Sie: Umgang mit Tokens, Scope-Fehler und die Prüfung, dass ein Request ohne Berechtigung auf die richtige Art fehlschlägt und nicht bloß generisch.

Open-Meteo

  • Wettervorhersagen, ohne Schlüssel, mit veröffentlichter Fair-Use-Policy.

  • Üben Sie: Kombinationen von Query-Parametern und zeitabhängige Daten, bei denen sich die richtige Antwort von Lauf zu Lauf ändert. Gutes Training für Assertions, die keine exakten Übereinstimmungen sein können.

HTTPBin, noch einmal

  • Üben Sie: Basic Auth und Bearer-Token-Flows gegen Endpunkte, die genau dafür gebaut wurden, ohne fremde Kontingente aufs Spiel zu setzen.

Drei Assertions, die sich an jeder öffentlichen API zu üben lohnen

Welchen Dienst Sie auch wählen: Das sind die Gewohnheiten, die sich auf Ihre eigene API übertragen.

  • Prüfen Sie den Body, nicht nur den Status. Ein 200 mit einer leeren Liste, wo ein Datensatz stehen müsste, ist ein Bug, den eine Assertion auf den Statuscode bereitwillig als bestanden durchwinkt. Diese eine Gewohnheit findet mehr echte Defekte als jede andere.

  • Prüfen Sie, dass Fehlerfälle richtig fehlschlagen. Fragen Sie etwas an, das es nicht gibt, und prüfen Sie, ob Sie den richtigen Code und eine brauchbare Fehlerstruktur erhalten. Dienste, die einen 200 mit einem Fehlerobjekt darin zurückgeben, sind verbreitet, und eine Suite, die das nicht weiß, meldet für immer Grün.

  • Prüfen Sie Beziehungen, nicht nur Felder. Wenn ein Post auf einen Benutzer verweist, rufen Sie den Benutzer ab und prüfen Sie, ob es ihn gibt. Die interessantesten Bugs sitzen zwischen zwei Endpunkten, nicht innerhalb eines einzelnen.

Einen Agenten darauf ansetzen

Wenn Sie sehen wollen, wie generierte Testabdeckung aussieht, bevor Sie es an Ihrem eigenen Dienst versuchen, ist eine öffentliche API ein sicherer Ort dafür. Es gibt keine Daten zu verunreinigen und keine Umgebung, die kaputtgehen kann.

Richten Sie ein Projekt auf die Basis-URL und lassen Sie die Discovery die Endpunkte erfassen, und lesen Sie dann den generierten Plan, bevor Sie irgendetwas ausführen. Der Plan ist der interessante Teil. Auf zwei Dinge lohnt es sich dabei zu achten.

  • Erfasst er Werte, statt sie fest zu verdrahten? Ein Create-Aufruf liefert einen Identifier zurück, und der nächste Aufruf sollte ihn verwenden. Fest verdrahtete Identifier sind der übliche Grund, warum eine Suite genau einmal funktioniert.

  • Bringt er abhängige Aufrufe in die richtige Reihenfolge? Sie können keinen Kommentar zu einem Post abrufen, der nie erstellt wurde. Achten Sie darauf, ob der Plan das versteht oder Endpunkte einfach alphabetisch auflistet.

Führen Sie ihn dann aus und lesen Sie die Fehlschläge. Bei einer öffentlichen API liegen die meisten Fehlschläge an Ihren Annahmen und nicht am Dienst, und genau das ist die Lektion.

Wenn Sie den Testcode lieber selbst besitzen möchten, geht das CLI für Backend-Arbeit einen anderen Weg: Sie schreiben Aufrufe und Assertions selbst in Python, deklarieren, was jeder Test benötigt und produziert, und kennzeichnen das Aufräumen als eigenen Test. Das ist anfangs mehr Aufwand und legt die Suite in Ihr Repository, was manche Teams wollen und andere nicht.

Vom Üben zum eigenen Dienst

Der Abstand zwischen dem Üben an einer öffentlichen API und dem Testen der eigenen ist größer, als er aussieht, und zu wissen, wo der Schwierigkeitsgrad springt, erspart einiges an Frust.

Öffentliche APIs sind aus Ihrer Sicht zustandslos: Sie lesen, und was Sie schreiben, bleibt entweder nicht erhalten oder spielt keine Rolle. Bei Ihrem eigenen Dienst ist es umgekehrt. In dem Moment, in dem Sie etwas Echtes testen, erben Sie Authentifizierungen, die ablaufen, Datensätze, die vor anderen Datensätzen existieren müssen, Werte, die es nur zur Laufzeit gibt, und die Pflicht, hinter sich aufzuräumen.

Nichts davon kommt in einem Tutorial vor, und alles davon kommt in der ersten Woche vor. Betrachten Sie die Phase mit öffentlichen APIs deshalb als das Erlernen von Assertions, das sich vollständig überträgt, und rechnen Sie damit, dass der Umgang mit Zustand etwas ist, das Sie danach separat lernen, und keine Fortsetzung derselben Fähigkeit.

Was Sie damit nicht tun sollten

  • Verwenden Sie sie nicht für Lasttests. Sie sind kostenlos, werden gemeinsam genutzt, und irgendjemand zahlt die Rechnung.

  • Bauen Sie keine produktive Abhängigkeit darauf auf. Nutzungsbedingungen ändern sich, Projekte werden archiviert, und Freiwillige werden müde.

  • Werten Sie eine grüne Suite gegen JSONPlaceholder nicht als Beleg dafür, dass Ihre eigene API korrekt ist. Sie sagt Ihnen, dass Ihr Test-Setup funktioniert, und das ist eine wirklich nützliche, aber deutlich kleinere Aussage.

Das Ganze an einem echten Dienst ausprobieren

Sobald die Assertion-Gewohnheiten sitzen, beginnen beim Sprung zur eigenen API die Zustandsprobleme, und genau diesen Teil übernimmt TestSprite als Produkt. Auto-Authentication hält Sessions über einen Lauf hinweg am Leben. Dynamic Variables tragen einen Identifier vom Create-Aufruf in den Delete-Aufruf. Dependency Chains ermitteln, was zuerst passieren muss. Auto-Cleanup entfernt, was der Lauf erzeugt hat.

Der Einstieg beim eigenen Dienst sieht aus wie die Übung mit öffentlichen APIs oben: Projekt auf die Basis-URL richten, die Discovery die Endpunkte erfassen lassen und den generierten Plan lesen, bevor irgendetwas läuft. Der Unterschied ist, dass der Plan nun Autorisierung und Grenzfälle abdeckt und der Lauf nichts zurücklässt.

An einer öffentlichen API lässt sich das gefahrlos zuerst ausprobieren, denn es gibt keine Daten zu verunreinigen, und der Plan sagt mehr über das Werkzeug aus als die Ergebnisse.

Mit welcher sollte ich anfangen?

JSONPlaceholder für die erste Stunde, weil dabei nichts schiefgehen kann. Danach HTTPBin, weil Sie dort Fehler gezielt erzeugen können, und beim Üben mit Fehlern liegt der Lerneffekt.

Braucht eine davon einen API-Schlüssel?

Die meisten in dieser Liste kommen ohne aus. GitHub funktioniert bei geringem Volumen ohne Authentifizierung, und ein Token zu besorgen lohnt sich gerade deshalb, weil Sie damit authentifizierte Flows üben können.

Kann ich sie in einer CI-Pipeline verwenden?

Für eine kleine Übungs-Suite ja. Für alles, was bei jedem Commit läuft, testen Sie stattdessen gegen einen lokalen Mock. CI auf einen von Freiwilligen betriebenen Dienst zu richten, ist der Weg, auf dem eine nützliche kostenlose Ressource aufhört, kostenlos zu sein.

Worin unterscheidet sich das von einer Postman-Collection öffentlicher APIs?

Eine Collection liefert Ihnen Requests. Diese Liste ist danach geordnet, was der jeweilige Dienst Ihnen beibringt, und das zählt mehr, wenn das Ziel ist, besser im Testen zu werden, statt einen einzelnen Aufruf zum Erfolg zu bringen.

Wie sehe ich am schnellsten, wie generierte Testabdeckung aussieht?

Richten Sie ein Projekt auf eine öffentliche Basis-URL, lassen Sie die Discovery die Endpunkte erfassen und lesen Sie den Plan, bevor Sie irgendetwas ausführen. Der Plan sagt mehr über das Werkzeug aus als die Ergebnisse.

Die Kurzfassung

Eine API auswählen, eine Fähigkeit üben, immer den Fehlerfall mitschreiben.

Öffentliche APIs sind der sicherste Ort, um zu lernen, wie gute Testabdeckung aussieht, denn es gibt nichts kaputtzumachen. Wenn Sie so weit sind, wenden Sie denselben Ansatz auf Ihren eigenen Dienst an und behalten Sie die Gewohnheit bei, Bodys, Fehlerfälle und Beziehungen zu prüfen.

Kostenlos starten Sprechen Sie mit uns