Il formato di una risposta in ajax - qualsiasi convenzione / raccomandazione?

Question

Il formato di una risposta in ajax - qualsiasi convenzione / raccomandazione?

#1 da (1 voti)

1

Dire che ho un sacco di pagine con ajax. C'è qualche convenzione o raccomandazione sul formato / struttura di una risposta ajax? Vale a dire, se c'è un errore, un server restituisce lo stato http 4xx o 5xx e ... quale struttura dovrebbe avere una risposta JSON? Dovrebbe essere con la chiave di livello root "errori"? Quale struttura dovrebbe avere un elemento di "errore"? O dovrebbe esserci una semplice serie di errori? Cosa succede se c'è stato un singolo errore?

Lo stesso vale per una risposta di successo: dovrebbe esserci un "nodo" di root-node, ad esempio? E così via.

Sono a conoscenza di jsonapi.org, ad esempio, ma è per le API pubbliche REST, mentre io uso ajax solo attraverso il mio sito web e quindi probabilmente sono l'unico utente e dovrebbe essere più semplice. Anche se sì, forse può essere utilizzato anche da altri siti web e da altri utenti.

coding-standards javascript rest conventions json

posta Dorion 20.04.2017 - 10:47

fonte

1 risposta

Leggi altre domande sui tag coding-standards javascript rest conventions json

Opzioni per le classi derivate di due classi base astratte Estrazione di dati da programmi di terze parti, ovvero creazione di un'API non ufficiale

score 1 · Answer 1

JavaScript asincrono e XML sono stati in gran parte abbandonati a favore di JSON e "REST", anche se il REST completo è raramente implementato.

Questo significa inviare codici di errore nel codice di risposta HTML e un messaggio di testo nel corpo come si vedrebbe con una normale richiesta HTTP fallita.

Questo ha diversi aspetti negativi, flusso di controllo per eccezione, codici di errore ambigui. Ma il vantaggio di essere semplice e non complicare il tuo oggetto di risposta con un possibile stato di errore.

Se si dispone di un risultato complesso, non di successo, da restituire come la convalida dell'input, suggerisco di strutturare l'oggetto restituito in modo specifico per includere tali risultati come esito positivo anziché tentare di inserirli in un messaggio di errore. ad esempio

HTTP 200
{
        "result":false
        "validationMessages" : [
            "username already in use",
            "password must contain at least one capital letter"
            ]
    }

Puoi vedere questo oggetto funziona egualmente bene sia per il successo che per l'errore, lasciando il codice HTTP per le eccezioni "reali" in cui gli errori di codice o il server non funzionano in qualche modo