Prüfen Sie, ob eine HTTP-Methode sicher oder idempotent ist
Erfahren Sie, ob sich eine Methode ohne Überraschungen wiederholen lässt: put mit Leerzeichen wird als PUT gelesen, nicht sicher, aber idempotent – zweimal gesendet hat es also dieselbe beabsichtigte Wirkung wie einmal. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Sie erhalten den normalisierten Methodennamen, zwei getrennte boolesche Ergebnisse und eine kompakte Gesamtklassifikation.
Sicher und idempotent sind zwei verschiedene Zusagen
Eine sichere Methode dient dazu, Informationen abzurufen oder zu erfragen, welche Optionen ein Server bietet, nicht dazu, dort etwas zu ändern. HEAD, OPTIONS und TRACE gehören dazu, und jede sichere Methode ist auch idempotent. Idempotent ist die weitere Zusage: Dieselbe Nachricht mehrmals zu senden, hat dieselbe beabsichtigte Wirkung wie ein einziges Senden. PUT und DELETE halten diese Zusage, ohne sicher zu sein, denn denselben Inhalt erneut abzulegen oder dasselbe Element erneut zu löschen, bringt keine neue Wirkung.
Wann Sie vor einer Wiederholung prüfen sollten
Wichtig wird die Frage vor allem, wenn eine Verbindung abbricht und unklar ist, ob der Server die Nachricht erhalten hat. Bevor Sie automatische Wiederholungen für eine Methode einschalten, prüfen Sie sie hier: Sie erhalten die Methode in Großbuchstaben, ob sie sicher ist, ob sie idempotent ist, und eine kurze zusammenfassende Bezeichnung. Groß- und Kleinschreibung und überzählige Leerzeichen zählen nicht, aus put wird PUT. Ein typischer Irrtum ist, idempotent für harmlos zu halten: DELETE ändert Daten, nur eben nicht zweimal. Unbekannte oder erfundene Namen werden abgelehnt statt erraten.
Bewerten Sie Wiederholungsversuche richtig
Idempotenz ist besonders wichtig, wenn Sie entscheiden, ob ein automatisierter Client eine Anfrage nach einem Verbindungsfehler wiederholen darf. Der Client weiß möglicherweise nicht, ob der Server den ersten Versuch empfangen hat. Durch die Wiederholung einer idempotenten Methode bleibt die beabsichtigte Wirkung der Anfrage erhalten.
Das garantiert weder gleiche Statuscodes noch identische Antworttexte. Beispielsweise kann ein erstes DELETE eine Ressource entfernen und Erfolg melden, während ein weiteres identisches DELETE darauf hinweist, dass die Ressource nicht mehr existiert; der angestrebte Endzustand bleibt dennoch derselbe. PUT besitzt dieselbe Eigenschaft, wenn Ziel und Repräsentation bei den wiederholten Anfragen gleich bleiben.
Anwendungsfälle
Wiederholungs-Middleware überprüfen
Prüfen Sie eine konfigurierte Methode, bevor Sie automatische Wiederholungen nach uneindeutigen Transportfehlern aktivieren.
Häufige Fragen
Warum ist DELETE idempotent, wenn der zweite Versuch einen anderen Status liefern kann?
Idempotenz betrifft die beabsichtigte Wirkung auf dem Server, nicht identische Antworten. Wiederholte Löschanfragen streben denselben Endzustand der Ressource an.
Werden Methodennamen in Kleinbuchstaben akzeptiert?
Ja. Die Prüfung entfernt umgebende Leerzeichen und normalisiert den eingegebenen Namen vor der Klassifikation in Großbuchstaben.
Was geschieht mit WebDAV- oder benutzerdefinierten Methoden?
Sie werden als unbekannt zurückgewiesen. Ihre Eigenschaften müssen aus der Spezifikation oder dem Anwendungsvertrag stammen, die sie definieren.
Was ist der Unterschied zwischen sicher und idempotent?
Eine sichere Methode fragt nur Informationen ab und verlangt keine Änderung auf dem Server. Eine idempotente darf etwas ändern, doch zweimal gesendet hat sie dieselbe beabsichtigte Wirkung wie einmal. PUT und DELETE sind idempotent, ohne sicher zu sein.
Welche Methoden werden erkannt?
Die neun Standardmethoden des Webprotokolls und der PATCH-Spezifikation, etwa PUT, PATCH, DELETE, HEAD, OPTIONS und TRACE. Groß- und Kleinschreibung sowie Leerzeichen um den Namen werden ignoriert, daher wird put als PUT gelesen.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/dev2/http-method-idempotent-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"method":"PUT"}'const res = await fetch("https://api.kit.forhosting.com/dev2/http-method-idempotent-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"method": "PUT"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/http-method-idempotent-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"method": "PUT"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/http-method-idempotent-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"method":"PUT"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"method":"PUT"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/http-method-idempotent-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"method": "PUT"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.http_method_idempotent_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Ordnen Sie eine Standard-HTTP-Methode anhand der in der HTTP-Semantik festgelegten Eigenschaften Sicherheit und Idempotenz ein. Geben Sie eine Methode wie GET, POST, PUT, PATCH oder DELETE ein. Die Prüfung kennt die neun Methoden aus den maßgeblichen Spezifikationen zur HTTP-Semantik und zu PATCH, ignoriert umgebende Leerzeichen sowie Groß- und Kleinschreibung und weist unbekannte Namen zurück, anstatt Eigenschaften von Erweiterungsmethoden zu vermuten.
Unterscheiden Sie Sicherheit und Idempotenz
Sicherheit und Idempotenz beschreiben unterschiedliche Zusagen. Eine sichere Methode dient zum Abrufen von Informationen oder zum Übermitteln von Optionen, nicht zum Anfordern einer Zustandsänderung auf dem Ursprungsserver. Idempotenz ist weiter gefasst: Mehrere identische Anfragen haben auf dem Server dieselbe beabsichtigte Wirkung wie eine einzelne Anfrage. PUT und DELETE sind idempotent, obwohl sie nicht sicher sind. Wird eine Repräsentation wiederholt durch dieselbe Repräsentation ersetzt oder die Löschung derselben Ressource mehrmals angefordert, kommt bei keiner Wiederholung eine neue beabsichtigte Wirkung hinzu. GET, HEAD, OPTIONS und TRACE sind sicher. Die HTTP-Semantik legt außerdem fest, dass jede sichere Methode idempotent ist. Deshalb erhalten diese Methoden die kombinierte Klassifikation `safe_and_idempotent`. Die Antwort weist `safe` und `idempotent` getrennt aus, damit Regelcode keine Eigenschaft aus einer Bezeichnung ableiten muss. Zusätzlich eignet sich das Feld `classification` zur Anzeige, Protokollierung oder einfachen Verzweigung. Diese Eigenschaften betreffen die standardisierte Anfragesemantik; sie besagen nicht, dass eine konkrete Implementierung fehlerfrei ist oder keinerlei unbeabsichtigte Nebenwirkungen aufweist.
Bewerten Sie Wiederholungsversuche richtig
POST und PATCH gelten nach ihrer allgemeinen Methodendefinition weder als sicher noch als idempotent. Eine bestimmte API kann einen wiederholbaren POST- oder PATCH-Vorgang entwerfen, etwa mit einem Idempotenzschlüssel oder einer bedingten Anfrage. Dieser Vertrag auf Anwendungsebene ändert jedoch nicht die standardmäßige Eigenschaft der Methode. Nutzen Sie das Ergebnis als Protokollgrundlage und berücksichtigen Sie anschließend stärkere Garantien, die von der aufgerufenen API ausdrücklich dokumentiert werden.
Validieren Sie Namen vor der Regelanwendung
Umgebende Leerzeichen werden entfernt und die Eingabe wird in Großbuchstaben umgewandelt. Wer die Eigenschaften einer Erweiterungsmethode aus ihrer Schreibweise errät, könnte eine unsichere Wiederholung erlauben oder einen gültigen Vorgang sperren. Verwendet Ihr System eine Erweiterungsmethode, prüfen Sie die registrierende oder definierende Spezifikation und behandeln Sie die Methode mit einer ausdrücklichen Regel. Der Algorithmus sendet keine Netzwerkanfrage und untersucht weder reale Server noch Routen, Caches, Proxys oder Anfragetexte. Die Prüfung akzeptiert die Standardnamen CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT und TRACE. Werte wie ` get ` und `patch` lassen sich daher normalisieren, ohne ihre Bedeutung zu verändern. Jeder andere Wert führt zu einem Fehler `invalid_input`. Dieses strikte Verhalten ist wichtig, weil HTTP-Methodentoken erweiterbar sind: WebDAV und andere Protokolle definieren zusätzliche Methoden, und private APIs können eigene Token einführen. Er arbeitet deterministisch und eignet sich für Linter, Prüfungen von API-Dokumentation, die Konfiguration von Wiederholungs-Middleware sowie Lernwerkzeuge im Browser.
Integrationsbeispiele
API-Dokumentation kontrollieren
Vergleichen Sie die Methoden von Endpunkten mit Dokumenten, die einen Vorgang als sicher oder idempotent bezeichnen.
HTTP-Semantik vermitteln
Zeigen Sie Sicherheit und Idempotenz gebräuchlicher Methoden mit einer deterministischen Abfrage getrennt an.
Technische Fragen
Ist jede sichere Methode auch idempotent?
Ja. Die HTTP-Semantik definiert sichere Methoden als idempotent; GET, HEAD, OPTIONS und TRACE besitzen daher beide Eigenschaften.
Ist PATCH idempotent?
PATCH ist standardmäßig nicht idempotent. Eine API kann einen wiederholbaren PATCH-Vorgang definieren; dies ist dann eine anwendungsspezifische Garantie.