Een aangenomen aanvraag heeft een zichtbare uitkomst nodig

Een succesmelding in het portaal moet de toestand onderbouwen waarop de gebruiker vertrouwt. Wie een voltooid rapport verwacht, heeft een opvraagbaar rapport nodig. Het aannemen van een aanmaakverzoek is een tussenstap. Dat onderscheid hoort bij de productbeslissing over terugkoppeling.

MDN beschrijft HTTP 202 als acceptatie van verwerking die nog niet voltooid is. Het werk kan later mislukken. Microsoft toont voor zulke asynchrone stromen een aparte statusopvraag. De HTTP-code van het eerste antwoord bepaalt dus nog niet wat het portaal daarna moet tonen.

Dezelfde acceptatie, twee interfaces

In ons fictieve portaal wordt rapporttaak J-73 aangenomen. Het sjabloon is eerst beschikbaar, maar wordt vóór verwerking verwijderd. De vergelijking hieronder beschrijft twee mogelijke interfaces, geen uitgevoerde gebruikerstest.

Beide interfaces kunnen hetzelfde antwoord op de aanvraag hebben ontvangen. Toch geven ze andere informatie. In A kan technische acceptatie een onvervulde functionele verwachting verhullen. B houdt de taak zichtbaar totdat de uitkomst vaststaat.

Een geslaagde statusopvraag kan een fout tonen

Onze voorbeeld-API geeft voor het succesvol lezen van de statusresource HTTP 200 terug met deze inhoud:

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

Het opvragen is gelukt; het maken van het rapport is mislukt. Veldnamen en antwoordontwerp zijn eigen voorbeeldregels, geen eisen voor iedere API. Een beoordeling die alleen geslaagde HTTP-aanroepen telt, kan deze taak missen. Aangenomen aanvragen, voltooide rapporten en mislukt werk beantwoorden verschillende vragen.

Is de statusopvraag zelf onbereikbaar, dan blijft de actuele werkstatus onbekend. Het portaal mag daaruit geen voltooid rapport of zeker mislukte taak afleiden. Ook een nieuwe klik moet bij de bestaande taak aansluiten, zodat extra aanvragen de onzekerheid niet vergroten.

Wanneer acceptatie als resultaat volstaat

Een functie die alleen aanvragen inneemt, kan haar afgesproken taak vervullen met blijvende registratie van de aanvraag. Dan past een bevestiging die duidelijk als acceptatie is benoemd. Een synchroon volledig afgeronde bewerking heeft evenmin uit principe een extra opvraagcyclus nodig.

Het rapportportaal heeft echter een ander doel: de gebruiker wil het bestand. De beoordeling van de integratie moet daarom tot dat resultaat en een traceerbaar foutpad reiken. Een snel eerste antwoord is dan een aparte eigenschap, geen bewijs van een beschikbaar rapport.

Bronnen

• MDN: 202 Accepted

• Microsoft: Asynchronous Request-Reply pattern