There are a few reasons why the update of a specific item may fail (e.g., the item has been deleted). The question I'm debating is how to return the result to the caller.
Touchstone: come lo faresti come pagina web?
Presumibilmente, l'utente inizierà a guardare una pagina web, con un modulo su di essa che le consentirebbe di descrivere l'attività - i lavori nel batch. Il pulsante di invio POSTerebbe il modulo alla risorsa identificata da form.action. La risposta sarebbe un'altra pagina html.
Espressa in termini REST, lo stato iniziale dell'applicazione verrebbe descritto da un documento ipermediale (la pagina html) con controlli ipermediali (collegamenti / moduli). L'applicazione rappresenterebbe i controlli basati sulla sua interpretazione del tipo di media (parametri del modulo). L'utente dovrebbe configurare e scegliere il controllo da attivare, che invierà un messaggio a una risorsa sul server, che risponderebbe con un altro documento ipermediale che descrive lo stato dell'applicazione successivo.
Questo è il livello 3 RMM, comunque. Fino a te quanto vuoi spingere verso questo obiettivo, ma trovo che è più facile lavorare all'indietro da "giusto" a "pratico".
I'm leaning towards returning a collection that contains only the items with failures, but I could see scenarios where it would be helpful to return the result for all of them.
Ancora, come gestiresti questo con le pagine web? Probabilmente rimanderai l'html che è più utile per il caso comune e includi un link ad altre risorse che descrivono il risultato con granularità diversa. Questo ti porterà nella versione 1, ma alla fine scoprirai che alcuni utenti preferiscono sempre la rappresentazione secondaria. Quindi imposterai una nuova risorsa che accetta il batch di lavoro e restituirà la rappresentazione secondaria (probabilmente con un collegamento al primo). La tua pagina web iniziale avrebbe due collegamenti su di essa, ognuno dei quali posterebbe lo stesso lavoro in batch su una risorsa diversa, in modo che l'utente possa esprimere la propria preferenza per una rappresentazione subito, eliminando il clic in più.
Puoi usare lo stesso trucco con altre rappresentazioni. A RMM-3, i tuoi documenti avrebbero controlli ipermediali per connettere l'applicazione ad altre rappresentazioni dei risultati, ma con RMM-2 puoi ottenere due risorse diverse che accettano lo stesso batch di lavoro e producono rapporti diversi.
Il punto chiave qui è che è un problema facile da affrontare in seguito, basta aggiungere un'altra risorsa che fa lo stesso lavoro.
Supponendo che si stia utilizzando HTTP per trasferire i documenti avanti e indietro, è probabile che il codice di stato corretto sia 201 (Creato). Non stai descrivendo il risultato del lavoro nel back-end, stai descrivendo ciò che sta accadendo alle risorse. Qui, presumibilmente stai prendendo la domanda che ha presentato il lavoro a "qualche rappresentazione dei risultati". A meno che non si abbia il viaggio nel tempo, il rapporto dei risultati probabilmente non esisteva prima che la richiesta arrivasse sul tuo server, quindi è naturale che tu stia creando una nuova risorsa (il documento che descrive i risultati).
Non è, per quanto posso vedere, particolarmente critico per farlo bene; restituire un 200 (OK) invece probabilmente va bene. Vi chiamo la vostra attenzione, perché trovo che pensare al documento aiuti a superare il blocco mentale di confondere la "risorsa" con la "cosa che sta effettivamente facendo il lavoro".
Vedi: REST in pratica di Jim Webber.