Una richiesta accettata deve avere un esito visibile

Un messaggio di successo nel portale dovrebbe attestare lo stato su cui l’utente fa affidamento. Chi si aspetta un report completo ha bisogno di un report recuperabile. L’accettazione della richiesta di creazione è un passaggio intermedio. Questa distinzione fa parte della decisione di prodotto sul riscontro all’utente.

MDN descrive HTTP 202 come l’accettazione di un’elaborazione non ancora completata. Il lavoro può fallire in seguito. Microsoft mostra una consultazione separata dello stato per questi flussi asincroni. Il codice HTTP della prima risposta non risolve quindi cosa debba mostrare il portale dopo.

Stessa accettazione, due interfacce

Nel nostro portale fittizio viene accettato il lavoro di report J-73. Il modello è inizialmente disponibile, ma viene rimosso prima dell’elaborazione. Il confronto seguente descrive due possibili interfacce, non un test utente svolto.

Entrambe le interfacce potrebbero aver ricevuto la stessa risposta di accettazione. Forniscono comunque informazioni diverse. In A, l’accettazione tecnica può nascondere un’aspettativa applicativa non soddisfatta. B mantiene visibile il lavoro finché non se ne conosce l’esito.

Una consultazione riuscita può mostrare un errore

La nostra API di esempio restituisce HTTP 200 per la lettura riuscita della risorsa di stato, con questo contenuto:

{"jobId":"J-73","status":"failed","error":{"code":"template-not-found"}}

La consultazione ha funzionato; la creazione del report è fallita. Nomi dei campi e struttura della risposta sono regole del nostro esempio, non requisiti per ogni API. Una valutazione che conta solo le chiamate HTTP riuscite potrebbe non rilevare questo lavoro. Richieste accettate, report completati e lavori falliti rispondono a domande diverse.

Se la consultazione dello stato è essa stessa irraggiungibile, lo stato attuale del lavoro resta sconosciuto. Il portale non dovrebbe dedurne né un report completato né un lavoro certamente fallito. Anche un nuovo clic deve essere collegato al lavoro esistente, per non aggravare l’incertezza con ulteriori richieste.

Quando l’accettazione è un risultato sufficiente

Una funzione limitata alla ricezione può completare il compito concordato con un’accettazione duratura. In quel caso è adeguata una conferma chiaramente indicata come accettazione. Allo stesso modo, un’operazione interamente completata in modo sincrono non richiede un ulteriore ciclo di consultazione per principio.

Il portale di report ha però un altro obiettivo: l’utente vuole il file. La valutazione dell’integrazione deve quindi arrivare fino a questo esito e a un percorso di errore tracciabile. Una prima risposta rapida è allora una proprietà distinta, non la prova di un report disponibile.

Fonti

• MDN: 202 Accepted

• Microsoft: Asynchronous Request-Reply pattern