REST-API-Client / Tester

Erstellen Sie HTTP-Anfragen mit Abfrageparametern, Headern, JSON- oder Formular-Bodys sowie Basic- oder Bearer-Authentifizierung und senden Sie sie, und prüfen Sie dann Status, Dauer und formatierte JSON-Antworten. Sie können einen bestehenden cURL-Befehl importieren oder die aktuelle Anfrage wieder als cURL kopieren. Möchten Sie wiederverwendbare Anfragen Schritt für Schritt aufbauen? Nutzen Sie den HTTP-Anfrage-Builder. Siehe auch die Familie der API-Werkzeuge.
Alles läuft lokal in Ihrem Browser. Anfragen über Ursprungsgrenzen hinweg unterliegen der CORS-Richtlinie des Zielservers — siehe den Hinweis unten, falls eine Anfrage fehlschlägt.
Abfrageparameter
Header
Body
Autorisierung
Optionen
Ist das Feld ausgefüllt, wird die Anfrage-URL an dieses Präfix angehängt. Nützlich für Server, die CORS blockieren.
200
Body Header

                                                                
Warum eine Anfrage fehlschlagen kann: Browser blockieren domänenübergreifendes Lesen, solange die API nicht Access-Control-Allow-Origin zurückgibt. Erlaubt das Ziel kein CORS, können Sie einen eigenen CORS-Proxy betreiben und dessen URL in das Proxy-Präfix oben eintragen oder den cURL-Umwandler nutzen, um die Anfrage stattdessen aus einem Terminal auszuführen. Bodys bei GET/HEAD werden ignoriert; ein WebSocket-Werkzeug finden Sie separat unter dem WebSocket-Tester.
HTTP-Methoden erklärt
Die von Ihnen gewählte Methode teilt dem Server mit, was mit der URL geschehen soll. Hier die Bedeutung der sieben Verben, die dieses Werkzeug senden kann:
GET — Ruft eine Ressource ab: eine Webseite, ein Bild, eine Liste von Datensätzen. „Ich möchte wissen, was unter dieser URL liegt.“ Die Anfrage ist nur lesend und gefahrlos wiederholbar; sie enthält normalerweise keinen Body (ein Body bei einer GET-Anfrage wird, falls vorhanden, ignoriert).
POST — Sendet neue Daten an den Server, meist um eine Ressource anzulegen oder eine Aktion auszulösen — ein Formular absenden, eine Datei hochladen, einen Auftrag starten. Die Nutzlast reist im Body der Anfrage. POST ist nicht idempotent: Wer dieselbe POST-Anfrage zweimal sendet, kann zwei Datensätze anlegen.
PUT — Ersetzt die gesamte Ressource unter der URL durch das, was Sie senden. Der Body muss die vollständige neue Version der Ressource enthalten. PUT ist idempotent: Die Wiederholung derselben Anfrage hat dieselbe Wirkung wie einmaliges Senden.
PATCH — Ändert nur einen Teil einer Ressource. Sie senden nur die Felder, die Sie aktualisieren möchten, z. B. {"email": "neu@example.com"}, statt des ganzen Datensatzes. Wählen Sie PATCH, wenn ein vollständiges PUT Sie zwingen würde, Felder erneut zu senden, die Sie nicht ändern.
DELETE — Entfernt die Ressource unter der URL. DELETE ist idempotent: Das Löschen von etwas, das bereits fort ist, liefert dasselbe Ergebnis (meist ein 404) und bewirkt beim zweiten Mal nichts mehr.
HEAD — Genau wie GET, aber die Antwort enthält nur Header — es wird überhaupt kein Body zurückgesendet. Verwenden Sie HEAD, um zu prüfen, ob eine URL existiert, wie groß eine Datei ist (Content-Length), wann sie zuletzt geändert wurde (Last-Modified) oder um welchen Typ es sich handelt (Content-Type), ohne die gesamte Nutzlast herunterzuladen.
OPTIONS — Fragt den Server, welche Methoden und Optionen für eine URL erlaubt sind, oder löst eine CORS-Vorabprüfung (Preflight) aus. Die Antwort-Header, etwa Access-Control-Allow-Methods, listen auf, was zulässig ist. OPTIONS enthält üblicherweise keinen Body; Browser senden sie oft automatisch vor einem domänenübergreifenden POST/PUT/PATCH/DELETE.
Leicht zu verwechseln: HEAD gegenüber GET — die Anfrage ist identisch, aber HEAD liefert keinen Body zurück. PUT gegenüber PATCH — PUT ersetzt die gesamte Ressource; PATCH wendet nur eine Teilaktualisierung der von Ihnen gesendeten Felder an.