Avvisi in un'API REST come errori non critici

9

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

Ora ho bisogno di un nuovo tipo di errore come un errore non critico, che dovrebbe fallire in modo normale, ma dovrebbe andare per l'azione in caso di invio di flag "supress avvertimenti". A tale utente può essere chiesto: "Sei sicuro di voler cambiare questo stato, non hai ancora finito"

Domanda : esiste una buona pratica per questo tipo di errori?

Domande secondarie :

Esiste una semantica HTTP per tale comportamento che posso utilizzare?
seguo ancora l'idea REST (per me sembra che lo faccia) - Lo tengo apolide

rest api

— user237329
fonte

Come decidi se mostrare un tale avviso a un utente? Si chiama un endpoint API per verificare lo stato dell'applicazione e quindi presentare all'utente tale finestra di dialogo, bloccando l'interfaccia utente fino a quando l'utente non risponde. Quindi si effettua la chiamata effettiva. Dovresti modellarlo anche con l'API REST: aggiungi un endpoint per verificare se è salvato per eseguire determinate attività. In questo modo qualsiasi utente API è in grado di effettuare controlli "pre-flight" e persino delegare una decisione a un utente. Il tuo approccio al codice di stato HTTP è come un rm /file"avviso" che il file viene letto di sola lettura mentre lo elimina comunque.

— Try-catch-finalmente

Ciò accade quando l'azienda è sovrapposta al codice di stato del protocollo. In ogni modo. Hai provato a usare il tuo codice di stato HTTP? Se Twitter può, anche tu. Diciamo ad esempio 6xx? Ad ogni modo, lo so finora, puoi aggiungere messaggi nel corpo della risposta anche se è 4xx (quale intervallo sarebbe apropiato nel tuo caso).

— Laiv

Finalmente ho usato 409 CONFLICTper la risposta di avviso. In questo modo, viene richiesto al client di forzare la chiamata con lo stesso endpoint e corpo con parametri exttra "force = 1"

— user237329

4

Non ci sono codici di risultato di avviso in http, si restituisce un successo (200) o un errore (400, 500). L'unica cosa che so potrebbe essere analoga a ciò che si desidera è qualcosa di simile al codice 401 "non autorizzato" - che è un vero fallimento, ma fa sì che la maggior parte dei client tenti di tentare 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 deve sapere questo informazioni per inviare il giusto codice risultato.

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

È possibile effettuare una richiesta al server per chiedere se l'utente può modificare lo stato del corso e seguire successivamente una richiesta appropriata.

— gbjbaanb
fonte

Non sto affatto dicendo che sia la cosa giusta da fare, ma i codici 3xx potrebbero essere visti come una sorta di avviso o codice di avviso in cui il cliente può decidere di procedere. Detto questo, preferirei o eseguire un'azione oppure no, e forse restituisco una risposta con informazioni aggiuntive nel corpo restituito o nelle intestazioni.

— Archimedix,

0

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

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

Ciò fornirebbe al codice lato client le informazioni necessarie per avvisare l'utente o intraprendere azioni correttive da solo.

— TMN
fonte

2

Non mi sono mai piaciute le risposte che dicono "Ho fallito con successo" :-)

— gbjbaanb