I codici Http non hanno nulla a che vedere con gli errori di business (validazione). Alcuni ppl usano i codici di errore HTTP per codificare il loro catatalog di errori. Ma non penso che sia una buona pratica.
Gli errori Http sono legati al protocollo (http). Quindi qualsiasi eccezione aziendale generata dal tuo codice dovrebbe essere (a mio parere) gestita e restituita come un missile. E naturalmente in una risposta da 200 Http.
Le eccezioni di runtime (errori imprevisti) possono essere restituite come Http 500 a meno che non si desideri controllare ogni possibile eccezione di runtime, gestirla e trasformarla in un messaggio di errore controllato (in questo caso, la risposta sarà Http 200).
Un errore 500 significa errore di non recupero . La azienda non può continuare, non esiste un flusso alternativo, quindi fine della richiesta e la tua richiesta non è stata elaborata .
Preferisco definire un messaggio di respone complesso: intestazione, corpo, attributi, ... e anche un codice interno che non segue i codici di risposta Http. Se il codice è informato, il server sta notificando qualcosa accanto al risultato del processo eseguito.
Gli unici codici che vorrei riutilizzare dal catalogo HTTP, sarebbero:
200: richiesta elaborata e risposta inviata. Se il processo aziendale ha avuto successo o meno, non importa. Abbiamo ricevuto la richiesta e siamo stati in grado di eseguire convalide, processi, ecc. Per ulteriori informazioni, consulta la pagina di risposta.
500: qualsiasi errore imprevisto. È successo qualcosa di sbagliato Non è legato al business, potrebbe essere qualcosa di finale. Tuttavia, il processo aziendale è terminato premedurale. Il cliente non ha bisogno di sapere cosa è successo. Potremmo dare troppe informazioni sul nostro sistema. Quindi lascia che l'errore diventi 500. Consenti al client di gestire.
403: accesso Forbbiden (e questo, non sempre. Solo se non ci sono affari speciali al client).
Altrimenti si stanno combinando protocol risposte con business risposte . Quindi, lato client, potrebbe cadere nell'errore di reindirizzamenti imprevisti, esecuzioni impreviste di fine flusso, ...
Modifica: finora, c'è lo standard da seguire. Qualsiasi stratagemma è giusto se si adatta ai tuoi requisiti