For example 500 Internal Server could imply that the apache server
internally has some permission issue.
Non necessariamente. Gli errori non collegati nell'applicazione lato server causeranno al server java un errore "controllato" 500.
Dal punto di vista del client web , 500 significa:
- Qualcosa è andato storto ( da qualche parte ) sul lato server . Non sappiamo cosa. Non riprovare la richiesta -
For everything, a 200 should be returned by the application code.
Il catalogo del codice di stato è più ampio , ma 200 è fondamentalmente il codice predefinito per dire: Ok, è andato tutto bene . Ti invito a consultare la lista dei codici di stato 2xx per arricchire la comunicazione tra client e server.
For example, if any exception is thrown within a service method then a
500 is returned to the client. Is the HTTP response convention broken
by Spring?
Va bene. Quando gli errori dell'applicazione raggiungono il server delle applicazioni, il server li intercetta e restituisce l'unico errore ragionevole per gli errori incontrollati. 500 .
In that case, because an exception might be thrown by application
code, shouldn't a 200 status code be returned?
Questo dovrebbe essere letto in questo modo:
- la richiesta ha avuto esito negativo -
Dal punto di vista della comunicazione, non mi sembra efficace. Di solito, i codici di errore 5xx significano: Provalo molto dopo , mentre i codici 4xx significano: Provalo di nuovo ma, questa volta, fallo bene . Restituzione di un codice 2xx quando la richiesta non è stata completata correttamente. Cosa stiamo comunicando al cliente?
Potremmo obiettare che il messaggio di testo dirà all'utente cosa fare, nonostante il codice di stato di de https, ma cosa succede se non ci sono utenti? Come programmare una comunicazione machine-to-machine se ogni chiamata termina "con successo"? Stringhe corrispondenti? Dichiarazione di codici di stato personalizzati? Non aggiungerebbe una complessità inutile?
Should the application code catch the error, return a 200 status code
and add a more business/application specific message.
Dipende. Se vuoi che la tua applicazione sia buon www citizen allora no, non dovresti. È positivo che le applicazioni Web facciano un uso appropriato del Web dell'architettura. Quindi, se è necessario comunicare un errore (5xx, 4xx) insieme a uno specifico messaggio di errore, quindi eseguirlo. Dillo al client web: la richiesta non è stata elaborata a causa dei seguenti errori
Let's say the application database is having issues? Or is it OK to
return the 500 message?
Va bene, per questo caso specifico, un codice di stato di 500 ha senso. Ma, in definitiva, dipende dai requisiti e dalle tue preferenze. Se sei preoccupato di come gestire la gestione degli errori con Spring Web, potrebbe interessarti i seguenti link 1 o 2 .