Progettazione di un'API REST: impostazione dei codici di errore della logica aziendale nelle intestazioni http o all'interno del payload della risposta

2

Sto progettando un backend di API REST che deve essere consumato da un front-end javascript.

Non sono sicuro di come comunicare gli errori di logica di business lato server (ad es. un utente che tenta di recuperare la sua password con un'e-mail sconosciuta, ecc.) al front-end.

Dopo aver impostato un codice di stato 40x sulla risposta, ho bisogno di aggiungere ulteriori dettagli sull'errore e sto esitando tra due opzioni:

  1. Impostazione di intestazioni HTTP personalizzate nella risposta (ad esempio X-Unknow-Email )
  2. Impostazione di un JSON nel payload della risposta HTTP con il corrispondente codice di errore

Qualcuno può essere già stato esposto a progettare API REST per favore dimmi quali sono i pro e i contro per le due soluzioni considerate sopra?

    
posta balteo 09.09.2015 - 15:07
fonte

2 risposte

2

Direi che l'opzione 2 rende più facile capire cosa è successo. Il cliente può sapere di guardare nel corpo un messaggio, che è la solita informazione sul posto trovata. Nella tua opzione 1, non solo il client deve sapere di guardare le intestazioni (che è più lavoro in molte librerie di rest client), ma dovrebbe anche sapere quali intestazioni da cercare. Nell'opzione 2, se necessario, puoi passare il messaggio di stringa all'utente e far capire a cosa significa. Penso che sia sicuro assumere che se si restituisce un codice di errore (non 2XX), il client non si aspetterà un'entità nel corpo della risposta, quindi è corretto sostituirlo con il messaggio.

    
risposta data 09.09.2015 - 16:36
fonte
3

Il modo migliore per farlo, nella mia esperienza, è descrivere una struttura di errore universale per la tua API. Qualcosa di simile potrebbe essere sufficiente:

{
  "errorCategory": "Authentication/Authorization",
  "errorMessage": "Unknown email provided as part of authentication",
  "errorDetailURL": "http://api.company.com/documentation/email_auth_error.html",
  "errorId": "some-kind-of-identifer"
}

Questo ti permette di fornire una categoria (che non cambierà, e quindi è utile per il codice client), un messaggio (che può cambiare ed è la soluzione migliore per il controllo e il test manuale), un URL più dettagliato (che può essere usato per fornire documentazione su come affrontare errori specifici, senza sprecare larghezza di banda), e un ID per questa istanza dell'errore, che può essere fornito al team di supporto se il cliente crede che sia un errore falso.

Può essere utilizzato sia in 40x che in 50x errori, e deve essere coerente .

    
risposta data 09.09.2015 - 16:33
fonte

Leggi altre domande sui tag