En modtaget forespørgsel skal have et synligt resultat

En succesbesked i portalen bør dokumentere den tilstand, brugeren stoler på. Den, der forventer en færdig rapport, har brug for en rapport, der kan hentes. Modtagelsen af bestillingen er et mellemtrin. Den forskel hører til produktbeslutningen om tilbagemeldingen.

MDN beskriver HTTP 202 som accept af behandling, der endnu ikke er afsluttet. Arbejdet kan fejle senere. Microsoft viser et særskilt statusopslag til sådanne asynkrone forløb. HTTP-koden i det første svar afgør derfor ikke, hvad portalen skal vise bagefter.

Samme modtagelse, to grænseflader

I vores fiktive portal modtages rapportopgaven J-73. Skabelonen er tilgængelig i starten, men fjernes før behandlingen. Sammenligningen nedenfor beskriver to mulige grænseflader, ikke en gennemført brugertest.

Begge grænseflader kunne have modtaget samme svar om accept. Alligevel giver de forskellige oplysninger. I A kan teknisk modtagelse skjule en uopfyldt forventning til resultatet. B holder opgaven synlig, indtil udfaldet er kendt.

Et vellykket statusopslag kan vise en fejl

Vores eksempel-API returnerer HTTP 200, når statusressourcen læses korrekt, med dette indhold:

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

Opslaget lykkedes; rapportoprettelsen mislykkedes. Feltnavne og svarform er vores egne eksempelregler, ikke krav til alle API'er. En vurdering, som kun tæller vellykkede HTTP-kald, kan overse opgaven. Modtagne forespørgsler, færdige rapporter og mislykket arbejde svarer på forskellige spørgsmål.

Er selve statusopslaget utilgængeligt, er arbejdets aktuelle tilstand ukendt. Portalen bør hverken udlede en færdig rapport eller en sikkert mislykket opgave af det. Et nyt klik skal også knyttes til den eksisterende opgave, så flere bestillinger ikke forværrer usikkerheden.

Hvornår modtagelse er et tilstrækkeligt resultat

En ren indleveringsfunktion kan opfylde sin aftalte opgave ved varig modtagelse. Her passer en bekræftelse, der tydeligt er mærket som modtagelse. Tilsvarende behøver en synkront afsluttet operation ikke en ekstra opslagscyklus alene af princip.

Rapportportalen har dog et andet mål: Brugeren vil have filen. Vurderingen af integrationen skal derfor række til dette resultat og en sporbar fejlhåndtering. Et hurtigt første svar er da en særskilt egenskab, ikke bevis på en tilgængelig rapport.

Kilder

• MDN: 202 Accepted

• Microsoft: Asynchronous Request-Reply pattern