Méthode HTTP pour action CRUD : verbe REST et code de statut
Saisissez create et obtenez la méthode conventionnelle avec 201 Created, un modèle de route et une note sur la convention ; update renvoie PUT pour un remplacement complet et signale PATCH pour les modifications partielles. Même action, même réponse, toujours. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Action
- create
- Statut
- 201
- Texte d'état
- Created
- Suggestion de chemin
- POST /resources
Il s'agit d'une correspondance déterministe, pas d'une estimation : la même action produit toujours la même réponse, sans aucun modèle impliqué. Les actions non reconnues sont rejetées avec une erreur claire énumérant les valeurs acceptées, de sorte qu'une faute de frappe dans l'automatisation échoue bruyamment au lieu de produire silencieusement une mauvaise route.
Pourquoi PUT pour update, et où PATCH s'insère
La case la plus débattue du tableau est update. PATCH existe pour l'autre cas courant, où le client n'envoie que les champs modifiés et où le serveur les fusionne ; la note renvoyée le précise explicitement, afin qu'un relecteur voie l'alternative au lieu de traiter la correspondance comme un dogme.
L'essentiel pour une conception est de choisir une convention et de l'appliquer uniformément à chaque ressource, ce qui est précisément le genre de décision qu'une recherche déterministe aide à faire respecter lorsqu'elle est intégrée aux outils de génération et aux listes de contrôle de revue de code.
Les codes de statut sont la moitié de la réponse
Choisir le verbe n'est que la moitié de la conception d'un point de terminaison ; le code de statut de succès est l'autre moitié, et se tromper déroute les clients. Un create qui répond 200 OK au lieu de 201 Created n'est pas cassé, mais il gaspille un signal que la spécification offre gratuitement, et les clients automatisés qui branchent sur le statut le malinterpréteront.
Un delete qui répond 200 avec un corps vide force le client à analyser du vide là où 204 No Content aurait tout dit dans la ligne de statut. La correspondance renvoyée ici associe chaque action au statut qu'un appel réussi devrait produire — 201 pour create, 200 pour read, update et list, 204 pour delete — accompagnée de la phrase de raison standard, de sorte que la documentation générée et les sections responses d'OpenAPI sortent correctes par construction.
Les erreurs sont délibérément hors de portée : la capacité ne répond qu'à la convention du chemin favorable, et rejette les noms d'action non reconnus avec un message clair énumérant les cinq valeurs acceptées plutôt que de deviner une correspondance approximative.
Questions fréquentes
Combien cela coûte-t-il ?
La même correspondance fonctionne aussi gratuitement dans votre navigateur sur cette page.
Quelles actions sont acceptées ?
create, read, update, delete et list. La correspondance est insensible à la casse et les espaces environnants sont ignorés ; tout le reste est rejeté avec une erreur qui énumère les valeurs acceptées.
Pourquoi PUT et non PATCH pour update ?
PUT est le remplacement complet idempotent conventionnel, et c'est ce que la correspondance renvoie. La note de la réponse signale PATCH comme le choix standard pour les mises à jour partielles, afin que vous choisissiez en connaissance de cause.
La réponse est-elle jamais aléatoire ou générée par un modèle ?
Non. La correspondance est une table déterministe fixe ; la même action renvoie toujours la même méthode, le même statut et la même note.
Une création doit-elle répondre 200 ou 201 ?
201 Created, en général avec un en-tête Location qui pointe vers la nouvelle ressource. Un 200 OK n'est pas faux, mais il gaspille un signal que la spécification fournit déjà, et les clients qui se fient au statut le liront mal.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre 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)Exemple de requête
{
"action": "create"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.http_method_from_action_suggest",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Le point de terminaison méthode HTTP pour action CRUD répond à la question que tout concepteur d'API se pose des dizaines de fois par jour : pour une action comme create, read, update, delete ou list, quelle méthode HTTP le point de terminaison doit-il utiliser, et quel code de statut un appel réussi doit-il renvoyer ? Vous envoyez un seul nom d'action et vous obtenez le verbe REST conventionnel, le statut de succès typique avec sa phrase de raison, une indication de chemin montrant comment la route s'écrit habituellement, et une courte note expliquant la convention. Utilisez-le pour générer des squelettes de routes, réviser une conception d'API, produire des ébauches OpenAPI, ou enseigner les conventions REST à une équipe qui confond sans cesse PUT et PATCH.
La correspondance conventionnelle, en un tableau
Ce point de terminaison renvoie exactement cette ligne du tableau, avec le raisonnement joint, de sorte que la réponse peut être collée dans un document de conception ou vérifiée dans un test sans relire un guide de style. REST associe les quatre opérations de persistance aux verbes HTTP, plus la lecture de collection dont toute API réelle a également besoin. Create correspond à POST sur la collection et répond conventionnellement 201 Created, souvent avec un en-tête Location pointant vers la nouvelle ressource. Read correspond à GET sur une ressource unique et répond 200 OK ; il est sûr et idempotent, c'est pourquoi les caches et les nouvelles tentatives peuvent se montrer agressifs avec lui. Update correspond à PUT lorsque le client remplace intégralement la ressource, en répondant 200 OK avec la représentation mise à jour ; le même point de terminaison est idempotent, donc une requête retentée ne cause aucun dommage supplémentaire. Delete correspond à DELETE et répond typiquement 204 No Content, puisqu'il ne reste plus rien à décrire. List correspond à GET sur la collection, répond 200 OK, et c'est là que vivent les paramètres de requête de pagination, de filtrage et de tri.
Pourquoi PUT pour update, et où PATCH s'insère
Cette capacité suit la lecture la plus stricte de la spécification HTTP : PUT remplace la totalité de la ressource par la représentation envoyée par le client, ce qui le rend idempotent — envoyer deux fois le même PUT laisse le serveur dans exactement le même état. C'est cette propriété qui fait de PUT la valeur par défaut conventionnelle pour un point de terminaison de mise à jour, et la réponse que cette API donne pour l'action update. En pratique, de nombreuses API de production utilisent PATCH pour les mises à jour partielles et réservent PUT au remplacement complet, et certaines ignorent PUT entièrement.
Cas d'intégration
Générer des routes REST
Produisez des squelettes de routes pour une nouvelle ressource avec le verbe et le statut conventionnels déjà renseignés pour chaque action CRUD.
Réviser une conception d'API
Comparez une liste de points de terminaison proposés à la correspondance conventionnelle et signalez les routes divergentes avant leur mise en production.
Enseigner les conventions REST
Offrez à une équipe une référence déterministe unique pour la question du verbe et du statut au lieu de la redébattre à chaque revue.
Questions techniques
Couvre-t-elle les codes de statut d'erreur ?
Non. Elle ne répond que pour le chemin de succès conventionnel : la méthode HTTP, le code de statut de succès typique et une brève explication de la convention.
Que se passe-t-il avec une action non reconnue ?
La requête échoue avec une erreur invalid_input dont le message nomme la valeur reçue et énumère les cinq actions acceptées.