Gestione degli errori di dominio nell'API

Naviga le tue risposte
3

Sto lavorando alla creazione di un'interfaccia API su un'architettura basata su domini.

Il livello dominio ha un gruppo di specifiche classi di eccezioni (cioè NameIsRequiredException , CannotPublishDraftException , ecc.) che vengono generate.

Vogliamo un approccio per gestire in modo pulito questi diversi tipi di errori senza un intero gruppo di blocchi try / catch nei nostri controller.

Abbiamo pensato di utilizzare potenzialmente il nome del campo nel livello dominio nella risposta API (ad esempio un'eccezione FieldRequired personalizzata che ha una proprietà nome campo). Tuttavia, questo non funziona poiché non esponiamo tutti i campi nella nostra API, oppure i nomi dei campi API potrebbero non corrispondere ai nomi del campo nel livello dominio (ad esempio description vs desc ) - in più siamo accoppiando i nomi dei campi nella nostra API ai nomi dei campi nel nostro modello di dominio.

Un altro approccio prevedeva l'utilizzo di gestori di eccezioni personalizzate (in primavera) per restituire errori specifici per ogni possibile eccezione (che probabilmente ci imporrebbe di avere eccezioni molto specifiche nel nostro livello dominio). Questo approccio probabilmente funzionerà, ma sembra che potrebbe avere problemi di prestazioni generali o di sovraccarico.

Ti stai chiedendo se esistessero altre strategie per gestire questa situazione.

    
posta NRaf 02.05.2018 - 12:15
fonte

3 risposte

2

Non è necessario scrivere try-catch -Blocks su tutto il controller.

1) Vorrei ricavare quelle eccezioni da un antenato comune

2) C'è ExceptionHandler che cattura eccezioni di un certo tipo e ti dà il controllo, cosa fare dopo. Nell'eccezione, potresti trasportare un messaggio, che viene restituito, tramite il corpo della risposta.

Riguardo ai problemi di sicurezza o alle astrazioni che perdono, non vedo alcun problema nel fornire nel corpo della risposta un motivo come missing required field "password" o Could not publish. Document is already published .

Di ocurse dovresti evitare di capovolgere le cose.

    
risposta data 04.05.2018 - 18:46
fonte
4

La risposta API corretta per qualsiasi errore nel livello dominio dovrebbe essere 500 errore del server.

Il compito di controllare se l'utente ha fornito l'input corretto dovrebbe avvenire da qualche altra parte, nel livello dell'applicazione o anche nel lato client (validazione lato client)

Nel tuo codice devi assicurarti di passare solo dati validi al livello del dominio. Se è successo che uno sviluppatore ha permesso di trasmettere valori errati, allora è sicuramente un bug e il codice di risposta appropriato dovrebbe essere 500

    
risposta data 02.05.2018 - 14:10
fonte
0

Lo stavo facendo molto estesamente nel momento in cui stavo ancora cercando di far funzionare architetture a strati nei progetti. Senza conoscere le tue esatte circostanze, sospetto che sia qualcosa di simile.

Risposta breve: non dovresti utilizzare nessuna di queste opzioni, dal momento che entrambe le estensioni di perdite , i campi o semplicemente una conoscenza generale di come funzionano le cose in altri oggetti.

Se si sta eseguendo una singola applicazione con una specifica logica aziendale (non una libreria o qualcosa per uso generale), basta scrivere quella logica negli oggetti di business. Se l'oggetto business decide che non può fare qualcosa, restituisce solo una forma di descrizione dell'errore adatta al tuo utente finale (che si tratti di esseri umani o macchine), senza la necessità di interpretarla in altri oggetti della tua applicazione.

In altre parole, non è necessario per avere un'astrazione intermedia di errori se non si hanno motivi validi e specifici per averlo.

    
risposta data 04.05.2018 - 11:15
fonte

Leggi altre domande sui tag

Come passare le credenziali al cliente Devo usare un unique_ptr con un tipo di array o un vettore?