En accepterad begäran behöver ett synligt resultat
Vid bakgrundsarbete måste portalen visa mottagande och utfall. En lyckad statusförfrågan kan visa att jobbet har misslyckats.
Ett meddelande i portalen om att arbetet är klart bör styrka det tillstånd som användaren förlitar sig på. Den som väntar på en färdig rapport behöver en rapport som går att hämta. Att en begäran om att skapa den har accepterats är ett mellansteg. Skillnaden hör till produktbeslutet om återkopplingen.
MDN beskriver HTTP 202 som acceptans av bearbetning som ännu inte avslutats. Arbetet kan misslyckas senare. Microsoft visar en separat statusförfrågan för sådana asynkrona flöden. HTTP-koden i det första svaret avgör därför inte vad portalen ska visa därefter.
Samma mottagande, två gränssnitt
I vår fiktiva portal accepteras rapportjobbet J-73. Mallen är först tillgänglig men tas bort före bearbetningen. Jämförelsen nedan beskriver två möjliga gränssnitt, inget genomfört användartest.
Jobbets tillstånd | Gränssnitt A | Gränssnitt B |
|---|---|---|
| Meddelar redan ”Rapporten är klar”. | Meddelar ”Mottaget för bearbetning” och visar jobbreferensen. |
| Fortsätter visa samma meddelande om att rapporten är klar. | Visar att rapporten skapas. |
| Låter meddelandet om att rapporten är klar stå kvar. | Visar felet och en väg till lösning. |
Båda gränssnitten skulle kunna ha fått samma svar om acceptans. Ändå ger de olika information. I A kan tekniskt mottagande dölja en ouppfylld förväntan på resultatet. B håller jobbet synligt tills utfallet är känt.
En lyckad statusförfrågan kan visa ett fel
Vårt exempel-API returnerar HTTP 200 när statusresursen läses korrekt, med följande innehåll:
{"jobId":"J-73","status":"failed","error":{"code":"template-not-found"}}Förfrågan fungerade; rapporten kunde inte skapas. Fältnamn och svarsutformning är våra egna exempelregler, inga krav på varje API. En utvärdering som bara räknar lyckade HTTP-anrop kan missa jobbet. Accepterade begäranden, färdiga rapporter och misslyckat arbete besvarar olika frågor.
Om själva statusförfrågan inte är tillgänglig är arbetets aktuella tillstånd okänt. Portalen bör inte dra slutsatsen att rapporten är klar eller att jobbet säkert har misslyckats. Även ett nytt klick måste kopplas till det befintliga jobbet så att fler beställningar inte förvärrar osäkerheten.
När mottagandet räcker som resultat
En ren inlämningsfunktion kan fullgöra sin avtalade uppgift genom beständigt mottagande. Då passar en bekräftelse som tydligt anger mottagandet. En synkront helt avslutad operation behöver heller ingen extra frågecykel enbart av princip.
Rapportportalen har dock ett annat mål: användaren vill ha filen. Utvärderingen av integrationen måste därför nå fram till det resultatet och en spårbar felhantering. Ett snabbt första svar är då en egen egenskap, inget bevis på en tillgänglig rapport.
Källor
Läs vidare
Alla artiklar
API:er & integration med ASES
ERP, CRM och webbutik smidigt sammankopplade