per "no dati disponibili" da un'origine dati esterna

Question

Scenario:

Una richiesta POST viene inviato ad elaborare un ordine che si tradurrà in recupero dei dati da un'origine dati esterna.

ci sono tre risultati possibili:

1. L'origine dati restituito i dati per la richiesta
2. Nessun dato è disponibile per la richiesta (questo è visto come un errore)
3. L'origine dati non potrebbe essere letta (può essere di manutenzione)

Una risposta ovvia per è 200: OK o 01.237.562,120418 millions(un'entità viene creata da questa richiesta).

Qual codici di stato sarebbe opportuno per e ?

codici di stato mi hanno preso in considerazione:

• 503: Service Unavailable quando origine dati è giù
• 500: Internal Server Error quando origine dati è giù
• 502: Bad Gateway quando "non sono disponibili dati"
• 404: Not Found quando "non sono disponibili dati"
• 403: Forbidden se "nessun dato disponibile"
• 412: Precondition Failed quando "non sono disponibili dati"

Answer 1

2) Guardando indietro a questo, sono d'accordo probabilmente dovrebbe essere un 204 No Content o forse un 200 con un corpo che indica alcun record o risorse potrebbe essere trovato a seconda la struttura è tornata. 404 vengono generalmente utilizzati quando l'URI della risorsa non esiste o una risorsa nell'URI non viene trovata nel caso di un servizio riposante.

3) 503 Servizio non disponibile

Il server è attualmente in grado di gestire la richiesta a causa di un sovraccarico temporaneo o di manutenzione del server. L'implicazione è che questa è una condizione temporanea che sarà alleviata dopo un certo ritardo. Se noto, la lunghezza del ritardo può essere indicata in un'intestazione Riprova dopo. Se non viene fornito alcun tentativo, il client DOVREBBE gestire la risposta come per una risposta 500.

Note: The existence of the 503 status code does not imply that a 
    server must use it when becoming overloaded. Some servers may wish 
    to simply refuse the connection. 

Answer 2

3) Sono d'accordo con 503 per questo

2) Francamente penso che un buon argomento potrebbe essere fatto per l'utilizzo di 204 nel caso in cui 2 È possibile includere metainfo nell'intestazione per indicare specificamente che cosa 'è andato storto '. Dipende davvero da quanto consideri questo caso come un "errore" a livello di API.

Se l'API stessa funziona come previsto, e la richiesta era a un endpoint valido, da un utente autenticato e autorizzato e non ha causato il malfunzionamento del server, quindi molto pochi degli errori di serie 400 o 500 sembrerebbero davvero applicare.

per esempio, 404 di solito significa l'URI chiamato non esiste, se esiste, quindi utilizzando il codice è fuorviante, almeno IMHO

**10.2.5 204 No Content** 

Il server ha soddisfatto la richiesta, ma non lo fa è necessario restituire un corpo-entità e potrebbe voler restituire la metainformazione aggiornata. La risposta PU MAY includere nuove o aggiornate metainformazioni sotto forma di intestazioni di entità , che se presente DOVREBBE essere associata alla variante richiesta .

Se il client è un agente utente, NON DEVE cambiare la vista del documento da quella che ha causato l'invio della richiesta. Questa risposta è destinata principalmente a consentire l'immissione di azioni senza causando una modifica alla visualizzazione del documento attivo dell'agente utente, sebbene qualsiasi metainformation nuova o aggiornata DOVREBBE essere applicata al documento attualmente nella visualizzazione attiva dell'agente utente.

La risposta 204 NON DEVE includere un corpo del messaggio, quindi è sempre terminato dalla prima riga vuota dopo i campi dell'intestazione.