Codice di stato HTTP per una richiesta parzialmente riuscita

Ho un'applicazione che invia messaggi agli utenti. In una richiesta di post viene trasferita una stringa XML composta da tutti gli utenti che dovrebbero ricevere quel particolare messaggio. Se uno qualsiasi degli utenti nell'elenco non esiste, restituisco l'elenco degli utenti mancanti al cliente per un'ulteriore valutazione.

Ora mi chiedo quale sarebbe il codice di stato corretto per l'applicazione dicendo che la richiesta è stata accettata ma c'erano cose che non potevano essere fatte.

Il problema verrebbe evitato se non fosse consentito includere gli utenti mancanti nell'elenco. Quindi il tentativo di invio otterrebbe solo un errore 4xx. Ma non ha senso formare l'API in questo modo. D'altra parte potrei considerare la condizione di errore puramente specifica dell'applicazione. Ma inviare un 200 semplicemente non sembra giusto. E sarebbe bello dare al cliente un suggerimento quando guardare in profondità nella risposta all'errore. ad esempio, per evitare di inviare messaggi a quegli utenti più e più volte

Ho affrontato un problema molto simile. In questo caso, ho restituito un file

207 Multi-Stato

Ora, questo non è HTTP rigoroso, fa parte dell'estensione WebDAV, quindi se non hai il controllo anche sul client, allora non va bene per te. Se lo fai, potresti fare qualcosa del genere:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
       <D:user>user-123</D:user>
       <D:status>success</D:status>
     </D:response>
     <D:response>
       <D:user>user-789</D:user>
       <D:status>failure</D:status>
     </D:response>
   </D:multistatus>

Ma ancora una volta, questa è un'estensione HTTP e devi avere anche il controllo del client.

Ho avuto lo stesso problema e ho finito per utilizzare due diverse soluzioni:

• Codice di ritorno HTTP 202: Accepted, che indica che la richiesta era a posto, ma non c'è alcuna garanzia che tutto sia andato come dovrebbe.
• Restituisce un valore normale 200nella risposta, ma includi un elenco di ciò che non è stato visualizzato nel corpo della risposta.

Il secondo di solito funziona meglio, ma il primo è ottimo se sei pigro o usi una coda per l'elaborazione.

Che dire dell'utilizzo di 206 contenuto parziale. So che 206 riguarda più gli intervalli, ma cosa succederebbe se potesse indicare una richiesta parzialmente riuscita?

L'HyperText Transfer Protocol si occupa della trasmissione delle cose. Non ha codici di errore per gestire gli errori a livello di applicazione.

Restituire 200 è la cosa giusta da fare qui. Per quanto riguarda HTTP, la richiesta è stata ricevuta correttamente, gestita correttamente e stai restituendo la risposta. Quindi, a livello HTTP tutto è OK. Eventuali errori o avvisi relativi all'applicazione eseguita su http dovrebbero essere all'interno della risposta. In questo modo eviterai anche alcuni fastidiosi problemi che potresti incontrare con i server proxy che potrebbero non gestire determinate risposte nel modo previsto.