En akseptert forespørsel trenger et synlig resultat

En suksessmelding i portalen bør underbygge tilstanden brukeren stoler på. Den som forventer en ferdig rapport, trenger en rapport som kan hentes. At bestillingen er mottatt, er et mellomtrinn. Dette skillet hører til produktbeslutningen om tilbakemeldingen.

MDN beskriver HTTP 202 som aksept av en behandling som ennå ikke er avsluttet. Arbeidet kan mislykkes senere. Microsoft viser et eget statusoppslag for slike asynkrone forløp. HTTP-koden i det første svaret avgjør derfor ikke hva portalen skal vise etterpå.

Samme mottak, to grensesnitt

I vår fiktive portal aksepteres rapportjobben J-73. Malen er først tilgjengelig, men fjernes før behandlingen. Sammenligningen nedenfor beskriver to mulige grensesnitt, ikke en gjennomført brukertest.

Begge grensesnittene kunne ha mottatt samme svar om aksept. Likevel gir de ulik informasjon. I A kan teknisk mottak skjule en uoppfylt forventning til resultatet. B holder jobben synlig til utfallet er kjent.

Et vellykket statusoppslag kan vise en feil

Vårt eksempel-API returnerer HTTP 200 for vellykket lesing av statusressursen, med dette innholdet:

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

Oppslaget virket; rapporten kunne ikke opprettes. Feltnavn og svarutforming er våre egne eksempelregler, ikke krav til alle API-er. En vurdering som bare teller vellykkede HTTP-kall, kan overse denne jobben. Aksepterte forespørsler, ferdige rapporter og mislykket arbeid svarer på ulike spørsmål.

Er selve statusoppslaget utilgjengelig, er arbeidets aktuelle tilstand ukjent. Portalen bør ikke utlede at rapporten er ferdig eller at jobben helt sikkert har mislyktes. Også et nytt klikk må knyttes til den eksisterende jobben, slik at flere bestillinger ikke forverrer usikkerheten.

Når mottak er et tilstrekkelig resultat

En ren innleveringsfunksjon kan oppfylle den avtalte oppgaven sin ved varig mottak. Da passer en bekreftelse som tydelig er merket som mottak. En synkront fullført operasjon trenger heller ingen ekstra oppslagssyklus bare av prinsipp.

Rapportportalen har likevel et annet mål: Brukeren vil ha filen. Vurderingen av integrasjonen må derfor nå frem til dette resultatet og en sporbar feilhåndtering. Et raskt første svar er da en egen egenskap, ikke bevis på en tilgjengelig rapport.

Kilder

• MDN: 202 Accepted

• Microsoft: Asynchronous Request-Reply pattern