Ajax - Errori di business in risposta

2

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.

    
posta Desorder 16.07.2013 - 02:19
fonte

1 risposta

2

Questo è un buon posto per utilizzare posticipati . Ecco implementazione di jQuery , ma non devi usare jQuery. In poche parole, tutte le chiamate ajax restituiscono una promessa a cui tutte le richiamate si legano. Quando la risposta ritorna dal server, la valuti tramite un metodo middleware ( then nell'implementazione di jQuery) e risolvi o rifiuti la promessa a seconda dello stato. In questo modo, i callback vengono attivati o meno in base allo stato, non a seconda che la richiesta di ajax sia riuscita o meno. Puoi anche utilizzare questo approccio del middleware per creare un'istanza o compilare un modello di errore ...

Nota : non modificare il codice di risposta HTTP a livello di intestazioni! Invia lo stato insieme ai dati in modo che tu sappia veramente se il server ha gestito la richiesta in modo prevedibile o meno.

    
risposta data 16.07.2013 - 02:34
fonte

Leggi altre domande sui tag