Avvertenze in un'API REST come errori non critici

Question

Avvertenze in un'API REST come errori non critici

#1 da (4 voti)
#2 da (1 voti)

7

Ho un'API REST che per alcuni entpoind come DELETE, POST o PUT ho alcune regole di validazione che possono restituire un errore.

Ora ho bisogno di un nuovo tipo di errore come un errore non critico, che dovrebbe fallire in un modo normale, ma dovrebbe andare a favore dell'azione se c'è un flag "avvertimenti supressioni" inviato. Un utente di questo tipo può chiedere: "Sei sicuro di voler cambiare questo stato, non hai ancora finito"

Domanda : esiste una best practice per questo tipo di errori?

Domande secondarie :

C'è qualche semantica HTTP per un comportamento del genere che posso usare?
continuo a seguire l'idea REST (per me sembra che lo faccia) - La tengo stateless

api rest

posta user237329 12.04.2016 - 23:52

fonte

2 risposte

Leggi altre domande sui tag api rest

Gestire la registrazione facoltativa nella libreria ad alte prestazioni Wrapping di enum da una libreria

score 4 · Answer 1

Non ci sono codici dei risultati di avviso in http, si ritorna un successo (200) o un errore (400, 500). L'unica cosa che so che potrebbe essere analoga a quello che vuoi è qualcosa come il codice 401 'non autorizzato' - che è un vero fallimento, ma induce la maggior parte dei client a riprovare automaticamente la connessione con le credenziali.

Per un'API REST devi dire al server lo stato della richiesta e come gestire il risultato - non puoi inviare un PUT e aspettarti un errore se il client non è finito, o se ha successo, il server ha bisogno per conoscere queste informazioni al fine di rispedire il giusto codice del risultato.

Quindi puoi inviare il flag 'warn warnings' con la tua richiesta, se non è impostato il server restituirà un codice di errore 409 (o simile), e se impostato, restituirà invece un codice di 200. All'utente non può essere chiesto 'vuoi cambiare questo stato' dopo che è stata inviata la modifica dello stato.

Potresti fare una richiesta al server per chiedere se l'utente può cambiare lo stato del corso e seguire successivamente una richiesta appropriata.

score 1 · Answer 2

Se si desidera consentire all'utente di ignorare la normale gestione degli errori, è possibile considerare di restituire uno stato 200 SUCCESS con informazioni aggiuntive nelle intestazioni HTTP estese. Ad esempio, puoi restituire

X-APP-STATUS: 422 Unprocessable entity
X-APP-SOURCE: Invalid ID 'fo0'

Questo darebbe al tuo codice lato client le informazioni necessarie per avvisare l'utente o intraprendere azioni correttive da solo.