2012-09-29 13 views
10

Sto facendo una chiamata AJAX per impostare il nome utente. Se il nome utente è già stato preso, quale codice HTTP dovrei restituire?Quale codice di errore HTTP restituire per nome già utilizzato?

+0

Possibile duplicato di [Quale codice di risposta HTTP per "Questo messaggio è già registrato?" (Http://stackoverflow.com/questions/9269040/which-http-response-code-for-this-email-is- già registrato) –

risposta

-2

Non esiste un codice HTTP per il nome già utilizzato. Si prega di vedere List of HTTP Status Codes.

Se si utilizzano le chiamate AJAX per impostare il nome utente, perché non mostrare l'errore in HTML? Questo è più user-friendly in quanto i visitatori potrebbero sapere che cosa significa l'errore effettivo, invece di vedere qualche codice 4XX.

+1

stavo per prendere il codice 4xx con jquery e visualizzare un messaggio di errore facile da usare. – Ryan

+0

non si è limitati a prendere cose con i codici di stato http. puoi invece prendere i messaggi di errore. Controlla l'API [jQuery su $ .ajax] (http://api.jquery.com/jQuery.ajax/). Il gestore 'success' dovrebbe aiutarti, basta controllare gli esempi nell'API. – rationalboss

+0

Come ho commentato di seguito, 200 è per il successo. Gli errori che completano le richieste garantiscono un codice di stato di errore. Spero che Ryan non si sia impegnato a restituire 200 quando la richiesta è fallita - è una cattiva idea tutt'intorno. –

7

Vorrei scegliere 422 Entità non elaborabile. Gli sviluppatori di Lot di rails lo usano per tutti gli errori di convalida.

E sì, è assolutamente opportuno valutare lo stato dell'errore e visualizzare il messaggio di errore con javascript. Ciò è particolarmente utile se si utilizzano le stesse azioni per un'API. Quindi le tue richieste ajax accedono alla stessa API che potresti esporre ad altri sviluppatori.

16

è possibile utilizzare 409 Conflict.otherwise 200 con messaggio di errore.

1

Non c'è nessuna regola qui, dipende da voi. Tuttavia, come ha detto @ rationalboss, ha senso restituire 200 con un messaggio poiché la richiesta HTTP è riuscita, l'errore non è correlato alla richiesta.

400 errori indicano che la richiesta non era corretta in qualche modo, come un verbo errato o parametri mancanti.

La domanda qui riguarda l'interpretazione, sia da parte dei client software che da parte degli utenti e potrebbe essere meglio evitare i codici di errore quando non si verifica un errore HTTP.

+1

Non sono d'accordo, ma come hai detto è una questione di opinione. Per me, un errore nel completamento della richiesta garantisce un codice di errore. Non voglio che un cliente controlli i dettagli nella risposta per sapere che qualcosa non va. Se restituisco OK, significa che è riuscito. Eventuali errori che completano la richiesta dovrebbero rientrare nella categoria 400, a meno che non si tratti di un'eccezione effettiva del server, caso in cui va a 500, ma mai 200. –

Problemi correlati