foutmeldingen moeten altijd problem+json formaat hebben

[melsk-r]

Originally created by fsamwel (https://github.com/VNG-Realisatie/BAG-Gemeentelijke-wensen-tav-BAG-Bevragingen/issues/105):

Conform de NL API strategie en vanwaaruit de API specificaties moet in foutsituaties altijd een antwoord in het gedefinieerde problem+json formaat worden teruggegeven. Dat gebeurt nu niet altijd.

1. Wanneer de response body wel correct is samengesteld, is de response header Content-Type "application/json" waar "application/problem+json" was verwacht. (bij foutmeldingen is charset m.i. minder belangrijk, zal niet vaak non-ascii tekens bevatten, maar charset=UTF-8 kan ook toegevoegd worden)

2. wanneer de api key ontbreekt, of wanneer een onjuiste api-key is gestuurd, wordt als body "Invalid API Key" gestuurd met als content-type "text/plain;charset=UTF-8". Dit moet een foutmelding geven zoals voor 401 is gedefinieerd in de API specificaties.

[melsk-r]

This comment originally might have been created by someone else.

@strijm wat is hier precies gewijzigd?

Een request met onjuiste API-key levert nog een Content-Type: text/plain response, geen problem+json.

[melsk-r]

This comment originally might have been created by someone else.

@fsamwel Dat komt doordat die fout niet door applicatie wordt gegenereerd maar door de API gateway. Het BAG team kan daar niets aan doen, omdat de request niet op onze server komt. Ik heb een verzoek ingediend bij het team dat de API gateway beheert om dat aan te passen voor de BAG en HC endpoints, maar dat verzoek is nog niet afgehandeld. Het is ook de vraag of dat verzoek ingewilligd kan worden. Het is een generiek systeem, dat voor alle API's een aantal fout situaties afhandelt en altijd op dezelfde manier een foutmelding teruggeeft. Differentiëren naar client lijkt me op dat punt niet wenselijk. Ik wacht dus even het antwoord af. Het gaat hier bv. om 401, 403, 429, 503 responses etc.

Als er fouten worden gegenereerd door de applicatie, dan hebben die (als het goed is) nu wel content type application/problem+json. Het gaat dan om bv. 400, 404, 406, 412 etc.

[melsk-r]

This comment originally might have been created by someone else.

@strijm dus als ik het goed begrijp is er niks gewijzigd op dit issue? Nicole gaf in haar e-mail namelijk aan dat deze in de oplevering van sprint 11 zat.

[melsk-r]

This comment originally might have been created by someone else.

@fsamwel Jawel, maar blijkbaar was mijn vorige opmerking niet helemaal duidelijk. Ik heb die een klein beetje aangepast. We hebben de applicatie zodanig aangepast dat foutmeldingen die wel door de applicatie worden gegenereerd nu wel application/problem+json bevatten (bv. bij 400, 404, 406 en 412).

[melsk-r]

This comment originally might have been created by someone else.

oké duidelijk, die situaties zaten in mijn test en gingen goed