Metodo HTTP per azione CRUD: suggerimento REST
Scriva create e ottenga il metodo convenzionale con 201 Created, un modello di percorso e una nota sulla convenzione; update restituisce PUT per la sostituzione completa e cita PATCH per le modifiche parziali. Stessa azione, stessa risposta, sempre. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Azione
- create
- Stato
- 201
- Testo di stato
- Created
- Suggerimento del percorso
- POST /resources
È una mappatura deterministica, non un'ipotesi: la stessa azione produce sempre la stessa risposta, senza alcun modello coinvolto. Le azioni non riconosciute vengono rifiutate con un errore chiaro che elenca i valori accettati, così un refuso nell'automazione fallisce in modo evidente invece di generare silenziosamente una rotta sbagliata.
Perché PUT per update, e dove si colloca PATCH
La cella più discussa della tabella è update. PATCH esiste per l'altro caso comune, in cui il client invia solo i campi modificati e il server li fonde; la nota restituita lo dichiara esplicitamente, così chi revisiona vede l'alternativa invece di trattare la mappatura come un dogma.
Ciò che conta per un design è scegliere una convenzione e applicarla in modo uniforme a ogni risorsa, esattamente il tipo di decisione che una ricerca deterministica aiuta a far rispettare quando è integrata negli strumenti di scaffolding e nelle checklist di code review.
I codici di stato sono metà della risposta
Una create che risponde 200 OK invece di 201 Created non è rotta, ma spreca un segnale che la specifica offre gratuitamente, e i client automatizzati che si basano sullo stato lo interpreteranno male. Una delete che risponde 200 con un corpo vuoto costringe il client ad analizzare il nulla, dove 204 No Content avrebbe detto tutto nella riga di stato.
La mappatura restituita qui abbina a ogni azione il codice che una chiamata riuscita dovrebbe produrre — 201 per create, 200 per read, update e list, 204 per delete — insieme alla reason phrase standard, così la documentazione generata e le sezioni responses di OpenAPI risultano corrette per costruzione. Gli errori sono deliberatamente fuori ambito: la capability risponde solo con la convenzione del percorso felice e rifiuta i nomi di azione non riconosciuti con un messaggio chiaro che elenca i cinque valori accettati, invece di indovinare una corrispondenza approssimativa.
Domande frequenti
Quanto costa?
La stessa mappatura è disponibile gratuitamente anche nel browser, su questa pagina.
Quali azioni sono accettate?
create, read, update, delete e list. Il confronto non distingue maiuscole e minuscole e gli spazi iniziali e finali vengono ignorati; qualsiasi altro valore viene rifiutato con un errore che elenca quelli accettati.
Perché PUT e non PATCH per update?
PUT è la convenzionale sostituzione completa e idempotente, ed è ciò che la mappatura restituisce. La nota nella risposta segnala PATCH come scelta standard per gli aggiornamenti parziali, così può scegliere consapevolmente.
La risposta è mai casuale o generata da un modello?
No. La mappatura è una tabella deterministica fissa; la stessa azione restituisce sempre lo stesso metodo, lo stesso codice di stato e la stessa nota.
Un'azione di creazione deve rispondere 200 o 201?
201 Created, di solito con un'intestazione Location che punta alla nuova risorsa. Un 200 OK non è sbagliato, ma spreca un segnale che la specifica già offre, e i client che decidono in base allo stato lo leggeranno male.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo 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)Esempio di richiesta
{
"action": "create"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.http_method_from_action_suggest",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Il metodo HTTP per un endpoint CRUD risponde alla domanda che ogni progettista di API si pone decine di volte al giorno: data un'azione come create, read, update, delete o list, quale metodo HTTP dovrebbe usare l'endpoint e quale codice di stato dovrebbe restituire una chiamata riuscita? Lei invia un singolo nome di azione e riceve il verbo REST convenzionale, il codice di stato tipico con la sua reason phrase, un suggerimento di percorso che mostra come si scrive di solito la rotta e una breve nota che spiega la convenzione. Lo usi quando crea lo scaffolding delle rotte, revisiona il design di un'API, genera scheletri OpenAPI o insegna le convenzioni REST a un team che continua a confondere PUT e PATCH.
La mappatura convenzionale, in una tabella
REST associa le quattro operazioni di persistenza ai verbi HTTP, più la lettura della collezione di cui ogni API reale ha bisogno. Create corrisponde a POST sulla collezione e risponde convenzionalmente 201 Created, spesso con un header Location che punta alla nuova risorsa. Read corrisponde a GET su una singola risorsa e risponde 200 OK; è sicura e idempotente, ed è per questo che cache e retry possono comportarsi in modo aggressivo. Update corrisponde a PUT quando il client sostituisce interamente la risorsa, rispondendo 200 OK con la rappresentazione aggiornata; lo stesso endpoint è idempotente, quindi una richiesta ripetuta non causa danni aggiuntivi. Delete corrisponde a DELETE e risponde tipicamente 204 No Content, dato che non resta nulla da descrivere. List corrisponde a GET sulla collezione, risponde 200 OK ed è dove vivono i parametri di query per paginazione, filtri e ordinamento. Questo endpoint restituisce esattamente quella riga della tabella, con il ragionamento allegato, così la risposta può essere incollata in un documento di design o verificata in un test senza rileggere una guida di stile.
Perché PUT per update, e dove si colloca PATCH
Questa capability segue l'interpretazione più rigorosa della specifica HTTP: PUT sostituisce l'intera risorsa con la rappresentazione inviata dal client, il che la rende idempotente — inviare due volte lo stesso PUT lascia il server esattamente nello stesso stato. È questa proprietà a rendere PUT la scelta convenzionale per un endpoint di aggiornamento e la risposta che questa API fornisce per l'azione update. In pratica molte API in produzione usano PATCH per gli aggiornamenti parziali e riservano PUT alla sostituzione completa, e alcune rinunciano del tutto a PUT.
I codici di stato sono metà della risposta
Scegliere il verbo è solo metà del lavoro di progettazione di un endpoint; il codice di stato di successo è l'altra metà, e sbagliarlo confonde i client.
Casi di integrazione
Scaffolding di rotte REST
Generi bozze di rotte per una nuova risorsa con verbo e codice di stato convenzionali già compilati per ogni azione CRUD.
Revisione del design di un'API
Confronti un elenco di endpoint proposti con la mappatura convenzionale e segnali le rotte che divergono prima che vadano in produzione.
Insegnare le convenzioni REST
Offra al team un unico riferimento deterministico per la questione verbo-e-stato, invece di ridiscuterla a ogni revisione.
Domande tecniche
Copre anche i codici di stato di errore?
No. Risponde solo per il percorso di successo convenzionale: il metodo HTTP, il codice di stato tipico di successo e una breve spiegazione della convenzione.
Cosa succede con un'azione non riconosciuta?
La richiesta fallisce con un errore invalid_input il cui messaggio indica il valore ricevuto ed elenca le cinque azioni accettate.