Sto creando un RESTful API per la creazione di utenti che impone indirizzi email unici:Quale codice di risposta HTTP per "Questa email è già registrata"?
successo POST /users: HTTP 201 Created
Se POST di nuovo lo stesso indirizzo di posta elettronica, quale dovrebbe essere il codice di risposta essere? 409 Conflict il codice di risposta appropriato?
Sì, 409 è la più appropriata codice di risposta qui. Anche se è probabile che tu stia tornando al successo, passi ancora a una risorsa che è descritta come una raccolta e POSTing una e-mail duplicata è sicuramente un conflitto con "lo stato attuale della risorsa" come una raccolta. Dovresti restituire un corpo di risposta con una descrizione del problema e collegamenti ipertestuali per aiutare a risolvere il problema, se possibile.
Grazie per aver confermato la mia impressione con la spiegazione! Non ho pensato alla parte iperlink, troverò sicuramente un buon modo per includerlo. – thatmarvin
Io uso spesso la (estensione WebDAV) HTTP 422Unprocessable Entity:
La richiesta è stata ben formato, ma era in grado di essere seguita a causa di errori semantici
Questa parte mi fa pensare che 422 sia inappropriato: "... ma non è stato in grado di elaborare le istruzioni contenute". Qui, non c'è alcuna ambiguità riguardo la semantica delle istruzioni - il server ha capito la richiesta, non ha intenzione di soddisfarla.(Inoltre preferisco usare i codici RFC 2616 se posso aiutarlo) – thatmarvin
Mentre la risposta accettata è corretta nel mostrare il codice di stato corretto per l'attività, voglio aggiungere che si sta introducendo una vulnerabilità di sicurezza.
Se si restituisce un 409 per la registrazione dell'account, si espone semplicemente un servizio per l'enumerazione degli account.
Dipende dall'applicazione, se l'API è pubblico o meno, ecc., È possibile che si desideri restituire un 201 anche se l'account non è stato creato.
+1 alla risposta Barts - per motivi di sicurezza. Di solito sono d'accordo che 409 è un buon codice di stato per sth. quello esiste già. Ma in un ambiente di account utente/autenticazione/autorizzazione ecc., Tenderei a non esporre gli account utente esistenti nel database.
Ovviamente ci sono altri meccanismi di gestione della sicurezza in questo luogo. Se non ti dispiace esporre un piccolo numero di account, potresti aggiungere un comportamento alla tua applicazione che restituisce 401 o 403 su numerosi 409 eventi da un IP.
Un'altra opzione (in generale) è quella di definire un codice di stato da solo per avere un 2xx diverso dalle varianti standard 2xx esistenti. Questa potrebbe essere un'opzione se non vuoi gestire un "già esiste" come un errore. Tuttavia, questo sarebbe considerato come non standard e avrebbe lo stesso carattere non sicuro come un 409 nel tuo esempio concreto.
Non penso sia una buona idea. Se la connessione viene effettuata tramite un proxy, i risultati potrebbero essere imprevedibili. – Cheery
Penso che sia una buona idea! Perché HTTP ha il codice di stato, quindi usali! È anche molto utile quando devi eseguire il debug in un secondo momento e avere solo file di accesso o altri file di registro, ma se c'è il codice HTTP ... :) – powtac
'409 - Conflict 'è una scelta molto buona per questo tipo di risposta. –