Potrebbe sembrare un'altra di quelle domande con "miglior modo" o "best practice", ma non sono riuscito a trovare nulla di simile che potesse darmi un po 'di luce.
Lo scenario ... ho alcune chiamate Ajax. Tutto funziona bene. Faccio le chiamate, restituisco i risultati, cambio campi, valori, colori. Niente di interessante qui.
Ma poi, ieri, stavo scrivendo un altro metodo Ajax. Fondamentalmente, due campi data per restituire il numero di giorni senza giorni festivi. Di nuovo, niente di interessante qui ... fino al punto in cui potrei passare le date non valide.
Ora, la mia domanda ... in un'interazione ajax, ogni volta che ho uno scenario in cui i dati trasmessi da una chiamata ajax non sono validi (capire non valido, la formattazione è sbagliata oi dati non si adattano ad alcun tipo di attività), dovrei rispondere a qualsiasi chiamata ajax che contiene dati non adatti ai miei processi lato server con uno stato http diverso di 200 o creare un modello con errori e messaggi e tutto il resto?
Ho trovato persone che si comportano come i modelli AjaxRespond e rispondono. Il mio punto qui è che se i dati non sono buoni, potrei rispondere a uno status http 200 e gestire il modello ajax per verificare se ci sono errori o meno, ma potrei anche rispondere a 500 e accertarmi che ci sia un errore.
Qui posso vedere due prospettive.
1- la chiamata ha avuto successo da parte di javascript / ajax e quindi 200 è il modo logico di rispondere. Questo suona come "Ho buone notizie e cattive notizie".
2- la chiamata è andata a buon fine ma i dati sono stati eliminati e quindi è stato restituito 500 (o qualsiasi altro stato adatto). Questo è più fare business logic all'interno di try / catches.