How to Test REST APIs in Your Browser — A Developer's Guide

Was ist API-Tests?

Jede moderne Web- und mobile Anwendung läuft auf APIs. Wenn Sie Ihren Twitter-Feed laden, eine Bestellung bei Amazon aufgeben oder das Wetter auf Ihrem Telefon überprüfen, geschieht im Hintergrund ein API-Aufruf. API-Tests sind die Praxis, Anfragen an diese Endpunkte zu senden und zu überprüfen, ob die Antworten korrekt sind — der richtige Statuscode, die erwartete Datenstruktur und angemessene Leistung.

Im Gegensatz zu UI-Tests zielt API-Tests auf die Schicht unterhalb der Benutzeroberfläche ab. Es erkennt Fehler früher, läuft schneller und deckt Szenarien ab, die schwierig über einen Mausklick im Browser auszulösen sind. Egal, ob Sie Ihre eigene API erstellen oder mit einem Drittanbieterdienst integrieren, zu wissen, wie man Endpunkte schnell testet, ist eine grundlegende Entwicklerfähigkeit.

HTTP-Methoden erklärt

REST-APIs verwenden standardisierte HTTP-Methoden, um die durchgeführte Aktion auf einer Ressource anzuzeigen. Hier ist eine schnelle Referenz:

Methode	Zweck	Hat Body
GET	Eine Ressource oder Sammlung abrufen	Nein
POST	Eine neue Ressource erstellen	Ja
PUT	Eine Ressource vollständig ersetzen	Ja
PATCH	Eine Ressource teilweise aktualisieren	Ja
DELETE	Eine Ressource entfernen	Selten

Wichtiger Unterschied: PUT ersetzt die gesamte Ressource — alle Felder, die Sie weglassen, werden entfernt. PATCH aktualisiert nur die Felder, die Sie im Anfragekörper einfügen. Die meisten APIs, die Aktualisierungen akzeptieren, verwenden PATCH für partielle Änderungen und PUT für vollständige Ersetzungen.

So testen Sie APIs in Ihrem Browser

Sie müssen Postman nicht installieren oder cURL-Flags auswendig lernen, um eine API zu testen. Der API Explorer auf JSONTech.net lässt Sie Anfragen im Browser-Modus für CORS-fähige APIs senden oder in den Proxy-Modus wechseln, wenn der Browser die Anfrage blockiert. So geht's:

1. Öffnen Sie das API Explorer Tool.
2. Wählen Sie die HTTP-Methode (GET, POST, PUT, PATCH oder DELETE) aus dem Dropdown-Menü.
3. Geben Sie die Endpunkt-URL ein. Zum Beispiel: https://jsonplaceholder.typicode.com/posts/1
4. Fügen Sie alle benötigten Header hinzu (wie Content-Type oder Authorization).
5. Wenn die Methode einen Body benötigt (POST, PUT, PATCH), geben Sie Ihre JSON-Nutzlast im Body-Editor ein.
6. Klicken Sie auf Send und überprüfen Sie die Antwort — Statuscode, Header und den formatierten JSON-Body.

Wenn der Browser einen CORS-Fehler meldet, wechseln Sie den API Explorer in den Proxy-Modus. Dann wird die Live-Anfrage über die Edge-Infrastruktur von JSONTech geleitet, sodass Sie direkt auf der Seite weiter testen können.

Beispiel: Einen Beitrag abrufen

GET https://jsonplaceholder.typicode.com/posts/1

Antwort (200 OK):
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\\nsuscipit recusandae consequuntur..."
}

Beispiel: Einen Beitrag erstellen

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json

{
  "title": "Mein neuer Beitrag",
  "body": "Dies ist der Inhalt meines Beitrags.",
  "userId": 1
}

Antwort (201 Created):
{
  "id": 101,
  "title": "Mein neuer Beitrag",
  "body": "Dies ist der Inhalt meines Beitrags.",
  "userId": 1
}

Verständnis von Anfrage-Headern

Header tragen Metadaten über die Anfrage. Sie teilen dem Server mit, welches Format Sie erwarten, wer Sie sind und wie die Verbindung sich verhalten soll. Hier sind die, die Sie am häufigsten verwenden werden:

Header	Zweck	Beispielwert
Content-Type	Format des Anfragekörpers	application/json
Accept	Format, das Sie in der Antwort wünschen	application/json
Authorization	Anmeldeinformationen für die Authentifizierung	Bearer eyJhbGciOi...
Cache-Control	Caching-Direktiven	no-cache
User-Agent	Identifiziert die Client-Anwendung	MyApp/1.0

Das Vergessen von Content-Type: application/json bei POST/PUT-Anfragen ist einer der häufigsten Gründe, warum APIs 400 Bad Request zurückgeben. Der Server weiß nicht, wie er den Body ohne diese Angabe analysieren soll.

Authentifizierungsmethoden

Die meisten Produktions-APIs erfordern eine Authentifizierung. Die drei Muster, auf die Sie am häufigsten stoßen werden:

Bearer-Token (JWT)

Der gebräuchlichste Ansatz für moderne APIs. Sie fügen ein Token im Authorization-Header hinzu:

{
  "headers": {
    "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    "Content-Type": "application/json"
  }
}

Basis-Authentifizierung

Kodiert den Benutzernamen und das Passwort als Base64-String. Einfach, aber nur über HTTPS sicher:

{
  "headers": {
    "Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ=",
    "Content-Type": "application/json"
  }
}

API-Schlüssel

Einige APIs verwenden einen benutzerdefinierten Header oder einen Abfrageparameter für einen statischen Schlüssel:

// Als Header
{
  "headers": {
    "X-API-Key": "sk_live_abc123def456"
  }
}

// Als Abfrageparameter
GET https://api.example.com/data?api_key=sk_live_abc123def456

Lesen von API-Antworten

Wenn Sie eine Anfrage senden, sagt Ihnen die Antwort genau, was passiert ist. Sie müssen drei Dinge lesen: den Statuscode, die Antwort-Header und den Body.

Statuscodes

Code	Bedeutung	Wann Sie es sehen
200	OK	Erfolgreiches GET, PUT, PATCH oder DELETE
201	Erstellt	Erfolgreiches POST, das eine Ressource erstellt
400	Ungültige Anfrage	Ungültiges JSON, fehlende erforderliche Felder, falsche Typen
401	Nicht autorisiert	Fehlendes oder abgelaufenes Authentifizierungstoken
403	Verboten	Gültige Anmeldeinformationen, aber unzureichende Berechtigungen
404	Nicht gefunden	Der Endpunkt oder die Ressource existiert nicht
500	Interner Serverfehler	Etwas ist auf der Serverseite kaputt gegangen

Antwort-Header

Achten Sie auf Header wie Content-Type (bestätigt das Antwortformat), X-RateLimit-Remaining (wie viele Anfragen Sie noch haben) und Retry-After (wann Sie es erneut versuchen sollten, nachdem Sie ein Limit erreicht haben).

JSON-Body

Der Antwort-Body ist der Ort, an dem Ihre Daten leben. Eine gut gestaltete API umschließt sie in einer konsistenten Struktur:

{
  "data": {
    "id": 42,
    "name": "Widget",
    "price": 9.99
  },
  "meta": {
    "request_id": "req_8f3a2b"
  }
}

Wenn etwas schiefgeht, erhalten Sie ein Fehlerobjekt anstelle eines Datenobjekts. Überprüfen Sie immer zuerst den Statuscode und analysieren Sie dann den Body entsprechend.

CORS: Was es ist und warum Sie Fehler sehen

Cross-Origin Resource Sharing (CORS) ist ein Sicherheitsmechanismus des Browsers. Wenn Ihr JavaScript, das auf localhost:3000 läuft, versucht, eine API auf api.example.com aufzurufen, blockiert der Browser die Anfrage, es sei denn, der Server erlaubt dies ausdrücklich über CORS-Header.

Der typische Fehler sieht so aus:

Zugriff auf fetch bei 'https://api.example.com/data' von Ursprung
'http://localhost:3000' wurde durch die CORS-Richtlinie blockiert: Kein
'Access-Control-Allow-Origin'-Header ist auf der angeforderten Ressource vorhanden.

Das ist kein Fehler in Ihrem Code — es ist der Browser, der die Sicherheit durchsetzt. Die Lösung muss von der Serverseite kommen. Häufige Umgehungen:

• Bitten Sie den API-Besitzer, Ihren Ursprung zu ihrem Access-Control-Allow-Origin-Header hinzuzufügen.
• Verwenden Sie einen Proxy — leiten Sie Anfragen über Ihr eigenes Backend (z. B. eine Next.js-API-Route oder einen einfachen Express-Server), um die Einschränkung des Cross-Origin vollständig zu vermeiden.
• Verwenden Sie ein browserbasiertes Tool mit Proxy-Option wie den API Explorer. Starten Sie im Browser-Modus für offene APIs und wechseln Sie in den Proxy-Modus, wenn JSONTech die Anfrage für Ihren Test weiterleiten soll.

CORS betrifft nur Browser. Tools wie cURL, Postman und serverseitiger Code unterliegen keinen CORS-Beschränkungen — sie laufen nicht in einer Browser-Sandbox.

Häufige Fehler beim API-Test

Dies sind die Fallstricke, die Entwickler — von Anfängern bis zu erfahrenen Ingenieuren, die zu unbekannten APIs wechseln — stolpern:

1. Vergessen des Content-Type-Headers. Das Senden eines JSON-Body ohne Content-Type: application/json führt dazu, dass die meisten Server die Anfrage ablehnen oder falsch analysieren.
2. GET verwenden, wenn Sie POST meinen. GET-Anfragen sollten niemals einen Body haben. Wenn Sie Daten senden, benötigen Sie POST, PUT oder PATCH.
3. Statuscodes ignorieren. Ein 200 mit einer Fehlermeldung im Body ist kein Erfolg. Überprüfen Sie immer den tatsächlichen HTTP-Statuscode.
4. Anmeldeinformationen in der URL fest codieren. Stellen Sie niemals API-Schlüssel oder Tokens in der Abfragezeichenfolge bereit, wenn Header eine Option sind — URLs landen in Serverprotokollen, im Browserverlauf und in Referrer-Headern.
5. Nur den glücklichen Pfad testen. Senden Sie fehlerhaftes JSON, leere Bodies, fehlende erforderliche Felder und ungültige Tokens, um zu sehen, wie die API tatsächlich mit Fehlern umgeht.
6. Rate-Limits nicht überprüfen. Viele APIs geben einen 429-Statuscode zurück, wenn Sie das Limit überschreiten. Überprüfen Sie proaktiv die X-RateLimit-Remaining-Header.
7. CORS-Fehler mit Serverfehlern verwechseln. Ein CORS-Fehler bedeutet, dass der Browser die Anfrage blockiert hat — der Server hat möglicherweise erfolgreich geantwortet, aber der Browser hat sich geweigert, Ihnen das Ergebnis zu zeigen.

Probieren Sie es selbst aus

Bereit, eine API zu testen? Öffnen Sie den API Explorer und versuchen Sie, eine GET-Anfrage an https://jsonplaceholder.typicode.com/users/1 zu senden. Sie sehen die vollständige Antwort — Statuscode, Header und formatierten JSON-Body — und wenn eine andere API durch CORS blockiert wird, können Sie sie im Proxy-Modus erneut testen.

Keine Downloads, keine Anmeldungen, keine Konfiguration. Wählen Sie einfach eine Methode, geben Sie eine URL ein und klicken Sie auf Senden.