2015-01-07 17 views
9

Stiamo costruendo una nuova API REST.Gestione codice errore API REST 500

Stavo sostenendo che il codice di errore 500 (Errore interno del server) non dovrebbe mai essere restituito.

Ora, ovviamente, se si conoscono i parametri del client errati o se si ha tutto sotto controllo e si può restituire un codice di errore appropriato (ad esempio 422).

Quindi, se un errore imprevisto si verifica il server potrebbe:

  1. NON catturare errori imprevisti in modo che 500 bolle fino al cliente
  2. rilevare eventuali errori imprevisti e restituiscono un po 'di codice di errore segnalando un "situazione inaspettata" (sinceramente non sono riuscito a trovare alcun codice di errore!)

Ci sono altre opzioni?

risposta

9

Si tratta di un errore del server, non di un errore del client. Se gli errori del server non dovessero essere restituiti al client, non sarebbe stato creato per loro una classe di codice di stato (ad esempio 5xx).

Non è possibile nascondere il fatto che si sia verificato un errore di programmazione o che alcuni servizi su cui si basa non sono disponibili e che certamente non è colpa del cliente. Restituire qualsiasi altro intervallo di codice in questi casi rispetto alla serie 5xx non avrebbe alcun senso.

RFC 7231 mentions in section 6.6. Server Error 5xx:

Il 5xx (Server Error) classe di codice di stato indica che il server è consapevole del fatto che esso ha errato o non è in grado di eseguire il metodo richiesto.

Questo è esattamente il caso. Non c'è nulla di "interno" nel codice "Errore interno server 500" nel senso che non dovrebbe essere esposto al client.

+0

capito e sono d'accordo. Stavo cercando di scoprire se è possibile fare una differenza se lo sviluppatore sta gestendo tutti i casi o meno. In realtà non ha senso pensare in questo modo. Non c'è differenza in uno sviluppatore che ha rilevato un errore imprevisto e ne ha restituito 500 o non lo ha rilevato: il test ha avuto esito negativo ed è questo il problema importante. – faboolous

+1

Se si desidera distinguere tra un'eccezione del server gestita e non gestita, è possibile farlo utilizzando la registrazione (sul lato server) o nel corpo della richiesta (quindi il client, in questo caso il test). – CodeCaster

+0

chiarimenti utili. Ma questo codice di stato 500 può essere restituito dal server a causa di problemi di formattazione nel corpo della richiesta? –

5

La vera domanda è perché genera un errore 500. Se è collegato a qualsiasi parametro di input, allora direi che dovrebbe essere gestito internamente e restituito come un errore di 400 serie. Generalmente un 400, 404 o 406 sarebbe appropriato per riflettere input errati poiché la convenzione generale è che una risorsa RESTful è identificata in modo univoco dall'URL e un URL che non può generare una risposta valida è una richiesta errata (400) o simile.

Se l'errore è causato da qualcosa di diverso dagli input esplicitamente o implicitamente forniti dalla richiesta, direi che un errore 500 è probabilmente appropriato. Quindi una connessione al database fallita o un altro errore imprevedibile viene accuratamente rappresentata da un errore di 500 serie.

+1

_ "Se è correlato a ** qualsiasi parametro di input ** [..]: 400" _ - cosa succede se l'errore è causato da un'eccezione di eccezione di dereference null non rilevata su una variabile di richiesta? È causato da un errore di programmazione (server), attivato dalla richiesta (client). E se la variabile richiesta non è richiesta dalla logica del server, ma il programmatore ha assunto (quindi non controlla)? Il punto è: la maggior parte dei framework web restituisce codici 5xx al rilevamento di terminazioni anomale del software server. Questo framework non può distinguere tra un errore client e server in quanto tale. – CodeCaster

+2

Vero, ma la domanda è stata formulata nel contesto di testare un presumibilmente nuovo servizio e sollecitare feedback su come la situazione dovrebbe essere gestita in definitiva. Se stavo testando nuovi servizi e generato un 500 casi di test dell'input del caso limite, lo contrassegnerei come un test fallito e lavorerei con lo sviluppatore per gestire lo scenario di test con un errore più descrittivo (400, 404, ecc.) O un richiesta opportunamente revisionata (200). Ci sono veramente imprevedibili fonti di 500 errori, ma puoi/dovresti difenderti il ​​più possibile, anche se questo è semplicemente dare un errore più informativo. – tokkov

2

In generale, i codici di risposta 5xx indicano errori non programmatici, ad esempio un errore di connessione al database o un altro errore di dipendenza di sistema/libreria. In molti casi, si prevede che il cliente possa inviare nuovamente la stessa richiesta in futuro e si aspetta che abbia successo.

Sì, alcuni web-framework risponderanno con codici 5xx, ma quelli sono in genere il risultato di difetti nel codice e il framework è troppo astratto per sapere cosa è successo, quindi il valore predefinito è questo tipo di risposta; questo esempio, tuttavia, non significa che dovremmo avere l'abitudine di restituire codici 5xx come risultato di un comportamento programmatico non correlato a sistemi fuori processo.Esistono molti codici di risposta ben definiti che sono più adatti dei codici 5xx. Non essere in grado di analizzare/convalidare un dato input non è una risposta 5xx perché il codice può accettare una risposta più adeguata che non lascerà il cliente pensando di poter inviare nuovamente la stessa richiesta, quando in realtà non possono farlo.

Per essere chiari, se l'errore riscontrato dal server era dovuto all'ingresso CLIENT, questo è chiaramente un errore CLIENT e deve essere gestito con un codice di risposta 4xx. L'aspettativa è che il cliente correggerà l'errore nella sua richiesta e invierà nuovamente.

È completamente accettabile, tuttavia, rilevare gli errori non elaborati e interpretarli come una risposta 5xx, ma tenere presente che è necessario includere ulteriori informazioni nella risposta per indicare esattamente cosa non è riuscito; e ancora meglio se è possibile includere tempi di SLA per affrontare.

Non credo sia una buona pratica interpretare "un errore imprevisto" come errore 5xx perché si verificano errori.

È un monitor di avviso comune che inizia a segnalare i tipi 5xx di errori, poiché questi in genere indicano sistemi guasti, piuttosto che codice non riuscito. Quindi, codice di conseguenza!

3

Hai suggerito "Rilevare eventuali errori imprevisti e restituire alcuni segnali di errore segnalando" situazione inaspettata "" ma non è stato possibile trovare un codice di errore appropriato.

Indovina cosa: Ecco a cosa serve 5xx.

0

80% delle volte, questo sarebbe causa di ingresso sbagliato in soapRequest.xml file di