HTTP-Methode und Statuscode für CRUD-Aktionen ermitteln
Geben Sie create ein und erhalten Sie die übliche Methode mit 201 Created, einen Routenhinweis und eine Notiz zur Konvention; update liefert PUT für den vollständigen Ersatz und verweist auf PATCH für Teiländerungen. Gleiche Aktion, gleiche Antwort, immer. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Aktion
- create
- Status
- 201
- Statustext
- Created
- Pfadhinweis
- POST /resources
Es ist eine deterministische Zuordnung, kein Raten: Dieselbe Aktion liefert stets dieselbe Antwort, ganz ohne Modell. Unbekannte Aktionen werden mit einer klaren Fehlermeldung abgelehnt, die die akzeptierten Werte auflistet – ein Tippfehler in einer Automatisierung schlägt also laut fehl, statt still eine falsche Route zu erzeugen.
Warum PUT für Update – und wo PATCH passt
Die am häufigsten diskutierte Zelle der Tabelle ist Update. PATCH existiert für den anderen häufigen Fall, in dem der Client nur die geänderten Felder sendet und der Server sie zusammenführt; der zurückgegebene Hinweis weist ausdrücklich darauf hin, damit ein Prüfer die Alternative sieht, statt die Zuordnung als Dogma zu behandeln. In der Praxis nutzen viele produktive APIs PATCH für Teilaktualisierungen, reservieren PUT für den vollständigen Ersatz und manche verzichten ganz auf PUT.
Entscheidend für einen Entwurf ist, eine Konvention zu wählen und sie einheitlich auf alle Ressourcen anzuwenden – genau die Art von Entscheidung, die eine deterministische Abfrage durchsetzen hilft, wenn sie in Gerüstbau-Werkzeuge und Code-Review-Checklisten eingebunden ist.
Statuscodes sind die halbe Antwort
Das Verb zu wählen ist nur die eine Hälfte des Endpunkt-Entwurfs; der Erfolgs-Statuscode ist die andere, und wer ihn falsch setzt, verwirrt die Clients. Ein create, das mit 200 OK statt 201 Created antwortet, ist nicht kaputt, verschenkt aber ein Signal, das die Spezifikation kostenlos bereitstellt, und automatisierte Clients, die nach dem Status verzweigen, deuten es falsch. Ein delete, das mit 200 und leerem Body antwortet, zwingt den Client, nichts zu parsen, wo 204 No Content in der Statuszeile alles gesagt hätte.
Die hier gelieferte Zuordnung paart jede Aktion mit dem Status, den ein erfolgreicher Aufruf erzeugen sollte – 201 für create, 200 für read, update und list, 204 für delete – samt Standard-Grundphrase, sodass generierte Dokumentation und OpenAPI-Abschnitte zu Antworten von vornherein korrekt ausfallen. Fehler sind bewusst ausgenommen: Die Fähigkeit beantwortet nur die Konvention des Erfolgsfalls und lehnt unbekannte Aktionsnamen mit einer klaren Meldung ab, die die fünf akzeptierten Werte auflistet, statt eine ähnliche zu erraten.
Häufige Fragen
Was kostet das?
Dieselbe Zuordnung läuft auf dieser Seite außerdem kostenlos in Ihrem Browser.
Welche Aktionen werden akzeptiert?
create, read, update, delete und list. Der Abgleich ignoriert Groß- und Kleinschreibung sowie umschließende Leerzeichen; alles andere wird mit einem Fehler abgelehnt, der die akzeptierten Werte auflistet.
Warum PUT und nicht PATCH für Update?
PUT ist der übliche idempotente Vollersatz, und genau das liefert die Zuordnung. Der Hinweis in der Antwort nennt PATCH als Standardwahl für Teilaktualisierungen, damit Sie bewusst entscheiden können.
Ist die Antwort jemals zufällig oder modellerzeugt?
Nein. Die Zuordnung ist eine feste deterministische Tabelle; dieselbe Aktion liefert stets dieselbe Methode, denselben Status und denselben Hinweis.
Sollte das Anlegen mit 200 oder 201 antworten?
Mit 201 Created, meist samt Location-Header, der auf die neue Ressource zeigt. Ein 200 OK ist nicht falsch, verschenkt aber ein Signal, das die Spezifikation bereits vorsieht, und Clients, die nach dem Status verzweigen, deuten es falsch.
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/dev/http-method-from-action-suggest \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"action":"create"}'const res = await fetch("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"action": "create"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/http-method-from-action-suggest",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"action": "create"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"action":"create"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"action":"create"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/http-method-from-action-suggest", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"action": "create"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.http_method_from_action_suggest",
"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
Die HTTP-Methode für CRUD-Aktionen beantwortet die Frage, die sich jeder API-Designer dutzendfach am Tag stellt: Welche HTTP-Methode gehört zu einer Aktion wie create, read, update, delete oder list, und welchen Statuscode sollte ein erfolgreicher Aufruf zurückgeben? Sie senden einen einzelnen Aktionsnamen und erhalten das übliche REST-Verb, den typischen Erfolgsstatus mit Grundphrase, einen Pfadhinweis zur üblichen Schreibweise der Route sowie eine kurze Erläuterung der Konvention. Nutzen Sie die Zuordnung beim Gerüstbau von Routen, bei der Prüfung eines API-Entwurfs, beim Erzeugen von OpenAPI-Skeletten oder wenn Sie einem Team die REST-Konventionen vermitteln, das PUT und PATCH ständig verwechselt.
Die übliche Zuordnung in einer Tabelle
REST bildet die vier Persistenzoperationen auf HTTP-Verben ab, ergänzt um das Lesen der Sammlung, das jede echte API ebenfalls benötigt. Create entspricht POST auf der Sammlung und antwortet üblicherweise mit 201 Created, oft mit einem Location-Header auf die neue Ressource. Read entspricht GET auf einer einzelnen Ressource und antwortet mit 200 OK; es ist sicher und idempotent, weshalb Caches und Wiederholungen damit großzügig umgehen dürfen. Update entspricht PUT, wenn der Client die Ressource vollständig ersetzt, und antwortet mit 200 OK samt aktualisierter Repräsentation; der Endpunkt ist idempotent, ein wiederholter Aufruf richtet also keinen zusätzlichen Schaden an. Delete entspricht DELETE und antwortet typischerweise mit 204 No Content, da es nichts mehr zu beschreiben gibt. List entspricht GET auf der Sammlung, antwortet mit 200 OK und beherbergt die Abfrageparameter für Paginierung, Filterung und Sortierung. Dieser Endpunkt liefert genau diese Tabellenzeile mit Begründung, sodass die Antwort ohne erneutes Lesen eines Styleguides in ein Designdokument eingefügt oder in einem Test geprüft werden kann.
Warum PUT für Update – und wo PATCH passt
Diese Fähigkeit folgt der strengeren Lesart der HTTP-Spezifikation: PUT ersetzt die gesamte Ressource durch die vom Client gesendete Repräsentation und ist damit idempotent – zweimal dasselbe PUT zu senden, hinterlässt den Server in exakt demselben Zustand. Diese Eigenschaft macht PUT zum üblichen Standard für einen Update-Endpunkt und zur Antwort dieser API auf die Aktion update.
Integrationsbeispiele
REST-Routen als Gerüst erzeugen
Erzeugen Sie Routen-Stubs für eine neue Ressource, bei denen Verb und Status für jede CRUD-Aktion bereits konventionsgemäß eingetragen sind.
Einen API-Entwurf prüfen
Gleichen Sie eine vorgeschlagene Endpunktliste mit der üblichen Zuordnung ab und markieren Sie abweichende Routen, bevor sie ausgeliefert werden.
REST-Konventionen vermitteln
Geben Sie einem Team eine einzige deterministische Referenz für die Frage nach Verb und Status, statt sie in jedem Review neu zu verhandeln.
Technische Fragen
Werden auch Fehler-Statuscodes abgedeckt?
Nein. Beantwortet wird nur der übliche Erfolgsfall: die HTTP-Methode, der typische Erfolgs-Statuscode und eine kurze Erläuterung der Konvention.
Was passiert bei einer unbekannten Aktion?
Die Anfrage schlägt mit einem invalid_input-Fehler fehl, dessen Meldung den empfangenen Wert nennt und die fünf akzeptierten Aktionen auflistet.