Devo Aggregare errori API Web?

Penso che la tua domanda sia un po 'opaca perché ci sono diversi tipi di errori.

Errori di connessione / autenticazione / posizione

Una parte (che gestisci in anticipo la maggior parte del tempo) se errori come: 404 non trovati, 401 non autorizzati, ecc. Questi sono il più delle volte interrompibili e restituiti direttamente.

Reindirizzamenti e altre posizioni

Anche cose come 302 spostate in modo permanente possono essere coperte prima dell'elaborazione dei dati reali.

Contenuto degli errori dei messaggi

Se tutto ciò è soddisfatto, si arriva al contenuto reale del messaggio:

Esempio: hai errori nei dati inviati: 422 entità non elaborabile (dallo standard webdav). Per questo potrebbe essere necessario avviare l'elaborazione reale. Leggere, analizzare il messaggio. Convalidare i contenuti ecc.

Solo per quest'ultima parte utilizziamo errori aggregati, perché diciamo che il messaggio non è valido e vogliamo essere chiari: "Ok è sbagliato, quindi cosa c'è di sbagliato in questo?"

Per esempio vedi: link che copre quella parte.

Conclusione

Quindi in generale: non combiniamo gli errori di base, ne inviamo solo uno e cerchiamo di gestirlo in base alle specifiche. Quindi non combinare: 401 non autenticato con 302 spostato in modo permanente. Non avrebbe senso. Il client ottiene 401 non autenticato e il gioco è fatto. Se corregge che ottiene il 302 spostato in modo permanente.

Per il contenuto inviamo una lista (in json ad esempio) con i dati errati inviati e cosa c'è di sbagliato in essa.

Gli errori di aggregazione possono diventare orribilmente complessi. Non solo hai la complessità di identificare ciò che è andato storto, devi identificare come e ramificarti un nuovo comportamento per informare l'utente dell'errore specifico. Inoltre, è necessario anche un certo comportamento per rilevare che si è verificato un errore ha e che deve iniziare ad aggregare e restituire gli errori invece di riprendere le normali procedure.

Una soluzione sarebbe quella di aggregare gli errori rilevati, quindi semplicemente informare gli utenti di ciò che è considerato dati di input validi. Nell'esempio di nome utente e password, se entrambi erano errati, la maggior parte dei siti web aggregava i due campi in errore, quindi visualizza semplicemente un messaggio di output statico per entrambi. E.g:

Username must begin with blah blah, be blah characters long and not contains special characters.

Password must be longer than blah characters long and contain one blah, one blah and one blah.

La seconda soluzione sarebbe quella di restituire semplicemente il primo errore che si ottiene e consentire all'utente di ritentare l'invio dei dati, per trovare altri errori.

Vantaggi della soluzione uno: l'utente probabilmente migliorerà l'esperienza a causa dell'aggregazione del feedback, ed è anche probabilmente abbastanza intelligente da essere in grado di rendere l'input valido dai messaggi ricevuti.

Vantaggi della soluzione due: il feedback sarà più veloce, ma restituirà solo un errore. L'utente dovrà reinviare per raccogliere più feedback che a loro volta potrebbero diventare frustranti. Tuttavia, sarà anche più facile da implementare e, allo stesso modo, l'utente dovrebbe arrivare alla fine.