Se il problema non è l'errore dell'utente / del client, il server dovrebbe restituire un errore 5xx. Un errore 4xx deve essere restituito solo se la richiesta > > < < non è corretto in qualche modo.
A seconda della situazione, 500 o 503 potrebbero essere appropriati:
-
Per quanto riguarda il cliente, i "fattori esterni" sono interni al tuo server / servizio. Quindi 500 potrebbe essere appropriato.
-
Se il problema si risolve da solo (o si risolve) in un periodo di tempo relativamente breve, 503 potrebbe essere appropriato.
Probabilmente uno di questi è OK.
Un'altra possibilità è quella di restituire un codice 5xx non standard. Nota che i codici di stato non standard (cioè non definiti nelle specifiche HTTP 1.1) non sono sbagliati. C'è un ampio precedente per fare questo ... incluso il precedente di altri RFC che definiscono codici extra; consulta la Lista dei codici di stato HTTP per esempi
di Wikipedia.
Ho notato un commento che suggerisce questo:
In that case I will go for 500, however your users might blame on you for the error.
A condizione di includere dettagli della causa del problema nel corpo delle 500 risposte (in un formato appropriato!), questo non dovrebbe essere un problema.
I'd output a proper page -- 200 code, informing them about the third-party call failure and will ask them to try it again later.
IMO, non è corretto. Un codice di 200 significa che la richiesta è riuscita ... che non ha in modo evidente. Supponendo che si tratti di un servizio RESTful, il cliente utilizzerà il codice di stato per decidere cosa fare dopo. Non dovrebbe essere una bugia. Se vuoi dire "riprova più tardi", dovresti inviare una risposta 503, possibilmente con un'intestazione Retry-After.