9 von 9
vs
Unterschiedliche SicherheitUnterschiedliche Idempotenz
- GET is safe, POST is not safe.
- GET is idempotent, POST is not idempotent.
- GET does not take a body, POST takes a body.
Was es tut
Die HTTP-Methoden-Referenz ist eine Schnell-Nachschlagetabelle für die neun HTTP-Anfragemethoden (RFC 9110). Für jede Methode zeigt sie die vier Eigenschaften, die im API-Design am meisten zählen — safe, idempotent, cacheable und nimmt einen Body — plus eine Beschreibung in klarem Englisch und ihren typischen Einsatz. Suche, filtere nach Eigenschaft, klicke eine Methode für den vollständigen Eintrag und vergleiche je zwei Methoden, um zu sehen, wo genau sich ihre Semantik unterscheidet.
So verwendest du es
- Suche nach Methodenname oder Bedeutung (z. B.
patch,partial). - Schalte die Safe / Idempotent / Cacheable-Filter um, um die Liste einzugrenzen.
- Klicke eine Methode, um ihre vollständige Beschreibung und typischen Anwendungsfälle zu lesen.
- Nutze Compare two methods (z. B. PUT vs. PATCH), um die semantischen Unterschiede zu sehen.
Beispiele
GET
Safe, idempotent, cacheable; retrieves a resource without changing it.
PUT vs. PATCH
Both modify a resource, but only PUT is idempotent (PATCH can have different effects when repeated).
POST vs. PUT
POST creates under a collection (server picks the URL, not idempotent); PUT puts a resource at a known URL (idempotent).
Gut zu wissen
- Safe vs. idempotent: safe heißt „keine Änderung am Serverzustand“; idempotent heißt „eine Wiederholung des Aufrufs hat denselben Effekt wie einer“. Alle safe Methoden sind idempotent, aber nicht umgekehrt (PUT und DELETE sind idempotent, aber nicht safe).
- Quelle: die Eigenschafts-Flags folgen RFC 9110 / RFC 9111 und der MDN-Referenz.
POSTgilt laut Spezifikation als cacheable, obwohl Caches POST-Antworten selten ohne explizite Direktiven speichern. - Verwandte Tools: HTTP Status Codes, JSON Formatter, URL Encoder.