Best Practice: i messaggi di errore dovrebbero essere gestiti dall'API o dall'App?

Per lo meno, l'api REST deve restituire un codice di errore (ad esempio 123) e / o una chiave di errore (ad esempio "cannotRegister") che l'applicazione può quindi prelevare per visualizzare un messaggio correlato. Questo aiuta anche quando hai a che fare con un'applicazione disponibile in più lingue. L'app può quindi selezionare il messaggio correlato dal pacchetto di risorse appropriato (traduzione). L'API non ha bisogno di sapere in quale lingua l'utente sta visualizzando l'applicazione.

Provo a gestire il maggior numero possibile di errori dall'API . In ambienti con più client questo aiuta a mantenere le cose coerenti e più facili da mantenere.

Quando si esegue la gestione degli errori tramite l'API, il semplice codice di stato non è sufficiente. L'approccio che prendo qui, è quello di fornire un ulteriore corpo di risposta all'errore che fornisca anche un messaggio leggibile dall'uomo oltre a un messaggio più dettagliato per lo sviluppatore e un link a ulteriori risorse che forniscano alcune spiegazioni aggiuntive. In JSON questo potrebbe apparire in questo modo:

{
    "status": 404,
    "code": 404-07,
    "message": "Ooops! Seems like the file does not exist.",
    "developerMessage": "File resource for path /uploads/foobar.txt does not exist.",
    "moreInfo": "http://www.mycompany.com/errors/404-07"
}

Esempio tratto da stormpath .

I client utilizzano quindi message leggibile dall'uomo e li presentano direttamente all'utente finale.

Per gestire i18n utilizziamo le intestazioni Accept-Language e Content-Language HTTP. I messaggi di errore vengono quindi recapitati nella lingua desiderata.

L'API dovrebbe fare tutto il possibile per fornire all'applicazione le informazioni necessarie su come procedere. Ma per l'utente, il messaggio è più probabile:

None - for things like updates, prefetch etc. or where retrying helps.
Tell them "it didn't work".
Tell them "it didn't work, it might work later".
Tell them "it didn't work, here's what you can do to fix it"
Tell them "it didn't work, give this cryptic information to the help desk". 

Ma dipende dall'applicazione decidere in merito, in base alla situazione e alle informazioni dal server. Il server non può sapere quale sarebbe un messaggio adatto per l'utente.

Inserisci semplicemente un URL della pagina di errore nel tuo file di configurazione (web.config se asp.net), che visualizza la pagina di errore nel caso in cui si sia verificato un errore.

Usando l'api? non ne ho mai sentito parlare, ma se è abbastanza globale da far scattare un messaggio su qualsiasi errore, allora potrebbe essere abbastanza buono ..

Utilizza la configurazione dell'app per attivare un errore di custome. Se non puoi usare il tuo codice, ma mettilo da qualche parte in risposta a qualsiasi richiesta, non importa quale tipo di richiesta, altrimenti avrai errori a scivolare!