Stiamo progettando un'API RESTful per restituire raccolte di documenti. La nostra implementazione iniziale utilizza i codici di stato HTTP per indicare se una richiesta non può essere soddisfatta. Questa sembra essere una best practice ampiamente accettata (si veda ad esempio here).Come devono essere gestite le eccezioni in un'API RESTful per i risultati della raccolta?
Di recente abbiamo riscontrato un problema in cui un utente stava caricando 1000 documenti. Uno dei recuperi del documento non è riuscito e quindi abbiamo restituito un codice di stato HTTP 500.
Un'alternativa sarebbe quella di restituire un codice di stato HTTP 200 con il payload con i 999 documenti che siamo stati in grado di recuperare, e quindi una raccolta di errori che indica quella che ha avuto esito negativo.
Questo approccio alternativo è una violazione dei principi RESTful? Come dovrebbe essere gestita questa situazione? Ci sono opzioni oltre a questi due approcci?
Grazie Vivin per l'input. Quindi immagino che una possibile linea di divisione sia se la situazione è considerata "eccezionale" o meno. Se lo è, deve essere restituito uno stato HTTP 500. Se la situazione non è un'eccezione e si può prevedere che si verifichi regolarmente come parte del normale utilizzo dell'API, allora forse un HTTP 200 è più appropriato, inviando le informazioni di errore nel contenuto del carico utile (ben documentato!). –
@JoeAlfano corretto. Se si tratta di un'eccezione * effettiva * da cui l'utente non può realmente eseguire il ripristino, un HTTP 500 va bene. Altrimenti, puoi fornire qualsiasi dato parziale che possiedi, insieme agli errori e l'utente può decidere come gestirlo. –