2015-03-24 10 views
5

Nel progettare gli errori di un API REST sembra essere una buona pratica da seguire codici HTTP standard (4XX e 5XX) e di includere un corpo (XML/JSON) con:I messaggi di errore di Shall REST API devono essere internazionalizzati?

  • breve messaggio
  • Descrizione
  • codice

la mia domanda è ... è essere internazionalizzato questi messaggi?

Tendo a pensare che mostrare un messaggio al client sia la responsabilità del lato client, e quegli errori API dovrebbero essere considerati come un accordo (formato e campo codice) tra l'app client e l'API, ma non devono essere considerati da default è perfetto per essere esposto direttamente al cliente, quindi la formattazione del messaggio finale "Ooops ... qualcosa non andava" deve essere eseguita dal lato client. In altri casi, posso vedere le distribuzioni API perché P.O. ha bisogno di cambiare "Oops" in "Uups" e cose del genere, sembra totalmente qualcosa di simile all'aspetto e all'aspetto dell'app client IMHO.

risposta

3

Avete ragione, la maggior parte delle volte non è necessario esporre le eccezioni REST al client, poiché gli errori REST sono troppo tecnici.

Ancora ci sono applicazioni che sceglieranno di consentire all'utente di "scavare nell'errore tecnico" - ma anche se questo è il caso, credo che l'utente finale capisca che ora siamo nell'area "detagli tecnici" e abbiamo vinto Prevedo che la traduzione del messaggio (+ traduzione di messaggi tecnici semplicemente non suona bene in altre lingue eccetto l'inglese)

2

Direi se l'intera API è internazionalizzata e il cliente può scegliere la lingua attraverso l'intestazione Accept-Language, allora anche gli errori API dovrebbero essere internazionalizzati.

+0

Non so se capisco ... il formato di comunicazione tra l'app client e l'API non è internazionalizzato poiché ad es. i valori delle proprietà nei messaggi di scambio JSON non dipendono dalla lingua dell'utente ... in altri casi il codice nell'app client deve essere specifico per ogni lingua. Quindi, ora ha affermato che siamo di fronte al punto del formato utente finale per i messaggi. Sei d'accordo sul fatto che il formato finale dei messaggi è una responsabilità del cliente? ... se "sì" ok ... allora se "no" mi chiedo quale sia l'obiettivo di quei messaggi di errore e direi che la risposta è: 1º codice app client, 2º sviluppatori. – Rafael

+0

Se questo è il caso allora ... i messaggi di errore interni che passano tra l'app del client e l'API devono essere tradotti in modo che i potenziali sviluppatori lo comprendano? ... vedo questa domanda molto meno critica e, personalmente, direi di no. Mi aspetto che il protocollo e i messaggi di errore interno siano in inglese. – Rafael

+0

Non esiste una regola di questo tipo che un'API debba utilizzare l'inglese. Se la tua azienda richiede che l'API sia internazionalizzata, il modo corretto per farlo è usare l'intestazione 'Accept-Language'. –

Problemi correlati