API-Entwicklung: Schneller debuggen, früher ausliefern
JWT-Debugging, HTTP-Statuscodes, JSON-Formatierung, Base64-Kodierung und URL-Encoding — die unverzichtbaren Browser-Tools für API-Entwickler.
Es ist 15 Uhr und die API gibt einen 401 zurück. Der Token sieht gültig aus. Der Endpunkt stimmt. Die Request-Header scheinen in Ordnung.
Man fügt das JWT in einen Decoder ein und sieht sofort das Problem: Der exp-Claim ist vor 12 Minuten abgelaufen. Die Token-Refresh-Logik hat einen Bug.
Dieses fünfsekündige Dekodieren hat eine Stunde Code-Starren erspart.
JWT-Debugging ist Alltagsarbeit
Wer mit einer modernen API arbeitet, hat ständig mit JWTs zu tun. Login-Tokens, Service-zu-Service-Auth, OAuth-Flows — sie sind überall.
Das Problem ist, dass ein JWT wie sinnloses Kauderwelsch aussieht:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Welche Claims hat er? Wann läuft er ab? Welcher Algorithmus wurde zur Signierung verwendet? Man kann es nicht erkennen.
Token einfügen, sofort Header, Payload und Ablaufzeit sehen. Keine Bibliotheken installieren. Keinen Code schreiben. Einfach Antworten.
HTTP-Statuscodes: Jenseits von 200 und 404
Schnell — was ist der Unterschied zwischen 401 und 403? Was ist mit 502 vs. 503? Wann sollte man 409 und wann 422 zurückgeben?
Die meisten Entwickler kennen die gängigen Codes, aber APIs geben Dutzende verschiedener Statuscodes zurück. Wenn man einen unerwarteten 429 oder einen verwirrenden 307 bekommt, muss man genau wissen, was er bedeutet.
Eine HTTP-Statuscode-Referenz sagt, was jeder Code bedeutet, wann man ihn verwendet und was die häufigsten Ursachen sind. Schneller als Googeln, und man muss keine Stack-Overflow-Debatten durchkämmen.
JSON-Formatierung ist Pflicht
APIs senden JSON. APIs empfangen JSON. Und meistens kommt dieses JSON als eine einzige komprimierte Zeile ohne Leerzeichen an.
{"users":[{"id":1,"name":"Alice","roles":["admin","editor"],"settings":{"theme":"dark","notifications":{"email":true,"push":false}}}]}
Versuch mal, darin ein fehlendes Komma zu finden. Oder zu prüfen, ob ein verschachteltes Feld existiert. Oder zwei Antworten zu vergleichen.
Komprimiertes JSON einfügen, mit ordentlicher Einrückung formatiert bekommen. Jetzt kann man es tatsächlich lesen, Fehler erkennen und Strukturen vergleichen.
Base64: Das Geheimnis der Auth-Header
API-Authentifizierung beinhaltet oft Base64-Kodierung. Basic-Auth-Header sind username:password Base64-kodiert. Binärdaten in JSON-Payloads werden Base64-kodiert. Zertifikatsinhalte, Webhook-Signaturen, verschlüsselte Werte — alles Base64.
Wenn etwas nicht funktioniert, muss man dekodieren, was tatsächlich gesendet wird. Oder einen neuen Wert zum Testen kodieren.
Ein Base64-Encoder/Decoder erledigt beides sofort in beide Richtungen. Kodierten String einfügen, Originalwert sehen. Neuen Wert eingeben, kodierte Version erhalten.
Häufiges Debug-Szenario: Der Basic-Auth-Header schlägt fehl. Man dekodiert ihn und entdeckt ein abschließendes Newline-Zeichen im Passwort. Im Code hätte man das viel länger gesucht.
URL-Encoding wird knifflig
Query-Parameter mit Sonderzeichen brauchen URL-Encoding. Leerzeichen werden zu %20 (oder +). Kaufmanns-Und wird zu %26. Schrägstriche werden zu %2F.
Das ist wichtig, wenn:
- Man Such-Endpunkte mit Benutzereingaben baut
- Query-Parameter selbst URLs enthalten (Callback-URLs, Redirect-URIs)
- Man debuggt, warum ein Parameter nicht korrekt geparst wird
- API-Keys Sonderzeichen enthalten
Ein URL-Encoder/Decoder zeigt genau, wie die kodierte/dekodierte Version aussieht. Besonders nützlich beim Debuggen von OAuth-Callback-URLs, die oft URLs-in-URLs sind und bei Doppelkodierung unlesbar werden.
Echter Debug-Workflow
So passen diese Tools in eine tatsächliche API-Debug-Session:
- Request schlägt fehl — HTTP-Statuscode-Bedeutung prüfen
- Auth-Problem? — JWT dekodieren, Claims und Ablauf prüfen
- Payload-Problem? — JSON formatieren, Struktur inspizieren
- Header-Problem? — Base64-Auth-Header dekodieren
- URL-Parsing? — URL dekodieren, Parameter-Encoding prüfen
Jeder Schritt dauert Sekunden. Die Alternative — Wegwerf-Skripte schreiben, CLI-Tools installieren oder Dokumentation durchwühlen — dauert Minuten bis Stunden.
Immer offen lassen
Ich habe diese Tools als angepinnte Browser-Tabs. Nicht weil ich Base64-Encoding nicht in Python kann oder JSON nicht in VS Code formatieren kann. Kann ich. Aber der Kontextwechsel zum Terminal, ein schnelles Skript schreiben und ausführen — das unterbricht den Debug-Flow.
Diese Tools sind Debug-Geschwindigkeit. Einfügen, Ergebnis sehen, Problem verstehen, Code fixen. Der schnellstmögliche Debug-Zyklus.
API-Entwicklung ist zu 50% Code schreiben und zu 50% herausfinden, warum der geschriebene Code nicht so funktioniert wie erwartet. Die richtigen Browser-Tools ersetzen nicht die IDE oder den Debugger — sie ergänzen sie, indem sie den "Herausfinden"-Teil schneller machen.