Modo corretto per informare la violazione delle regole aziendali durante l'analisi JSON

Question

Modo corretto per informare la violazione delle regole aziendali durante l'analisi JSON

#1 da (4 voti)

0

Abbiamo lo scenario seguente nella nostra azienda:

Ci sono alcuni oggetti business a cui sono associate delle regole di business. Uno di questi oggetti, Person, ha le seguenti regole:

Una persona deve avere un nome (cioè in termini di codifica non nulli, né vuoti)
Il nome di una persona non deve essere costituito esclusivamente da spazi e / o schede

L'oggetto business ha nel suo costruttore un parametro per nome, che usa un tipo non annullabile per ricevere il nome. In modo simile c'è una proprietà che memorizza il nome come un tipo non annullabile.

Nel costruttore viene generata un'eccezione ( MyException ) quando il nome è vuoto dopo aver ritagliato gli spazi e / o le schede.

C'è anche un backend che si occupa di questi oggetti usando REST api attraverso JSON

In questo momento stiamo usando una libreria (Jackson) per analizzare i dati JSON ricevuti nel nostro back-end. Abbiamo specificato nei nostri DTO che il campo per il nome non può essere nullo o mancante dall'oggetto JSON. In caso di deserializzazione di un oggetto JSON con un campo nome mancante / nullo, la libreria genera un'eccezione.

Se una persona ricevuta nel backend lancia MyException , il backend converte tale eccezione in un messaggio JSON dettagliato da inviare al client.

Ma se il JSON ricevuto di una persona non ha il campo 'nome' o è nullo, lasciamo che la libreria lanci la sua eccezione e questo è l'errore presentato al client.

La domanda è: l'eccezione generata dalla libreria di analisi deve essere considerata uguale a MyException dato che entrambe sono regole aziendali?

java domain-model json business-rules backend

posta IS1_SO 18.10.2017 - 20:23

fonte

1 risposta

Leggi altre domande sui tag java domain-model json business-rules backend

Big-O quando il valore numerico del caso peggiore è noto In che modo IEqualityComparerT.Equals e IEqualityComparerT.GetHashCode si comportano in presenza di dati non validi?

score 4 · Accepted Answer

A seconda del modo in cui questi errori vengono presentati all'utente dell'API, potrebbe essere OK o non consentito.

Per entrambi gli errori, è importante avere:

L'indicazione che qualcosa è andato storto. Con REST, ciò significa inviare un HTTP 403 o un codice di stato simile nella risposta. Inoltre, di solito si traduce in un JSON che è visivamente identificabile come errore (ad esempio nominando il nodo JSON radice error ).
Il campo interessato, ovvero name .
La descrizione dell'errore, cioè cosa è andato storto. Manca il campo name ? O è stato trovato, ma il valore non è valido? In altre parole, l'utente dovrebbe essere in grado di identificare l'errore nell'input.

Il tipo dell'eccezione sottostante non è necessario. Potrebbe essere MyApp.Something.Whatever.BusinessRules.InvalidUserNameException o JsonSerializer.Validation.NullFieldException . L'utente dell'API non si cura, e non dovrebbe vedere comunque i tipi, poiché ciò riflette l'implementazione e varierebbe se si rifatta il codice, o se ci si sposta in un'altra lingua o in una libreria di serializzazione.

Avere eccezioni dalla libreria JSON fianco a fianco con le tue eccezioni personalizzate è perfettamente normale.
Ma questo dovrebbe comunque portare a messaggi uniformi mostrati all'utente finale.

Una nota a margine sull'effettiva regola aziendale:

A Person's name mustn't consist solely of spaces and/or tabs

Perché no? Perché uno spazio bianco non di rottura (U + 00A0) può essere un nome valido, ma una scheda non lo sarebbe?

Se la tua intenzione è impedire agli utenti di rovinare il tuo sistema, fallirai comunque. Con Unicode, ci sono molti modi per fare cose divertenti che mostreranno molto ... bene (o che non verrà visualizzato affatto). Oppure puoi limitare i tuoi utenti all'intervallo [A-Za-z ] , il che sarebbe tecnicamente molto conveniente e renderebbe anche impossibile l'inserimento dei nomi della maggior parte delle persone nel mondo.

Altrimenti, non riesco a vedere un caso in cui l'utente inserisca per errore una scheda come nome e, se questo è un caso frequente, puoi controllare due volte l'interfaccia utente che incoraggia questo tipo di errori.