Update BAG & BRT Top10NL & BRK-DKK REST API's

Klopt, dit was op zich geen hele bewuste keuze aan onze kant en we beseffen ons dat dit bij een aantal gebruiker tot problemen leidt. De optie ‘nullable’ is true is van na de livegang van de BAG API, bij een andere API die ook gemigreerd was kregen gebruikers ook problemen met het feit dat we de velden ineens wel teruggaven. We hebben bij die API toen tijdelijk de oude API weer live gezet en in onze backend een optie geintroduceerd om per API te kunnen kiezen of velden weggelaten worden of opgenomen zijn met de waarde null. Omdat de gemigreerde BAG API inmiddels al een drie weken live staat kunnen we nu niet alsnog weer teruggaan naar het weglaten van velden, er zullen dan andere gebruikers zijn die hier last van krijgen.

Wat betreft de nieuwe BAG API: deze wordt door een ander team gerealiseerd die als ik jouw bericht lees andere keuzes maakt omtrent het weglaten van velden, ik zal dit intern oppakken.

In de BRK-DKK API hebben we zojuist een kleine wijziging doorgevoerd, het perceelnummers is een Integer geworden in de API specificatie in plaats van een string. In de kern zijn we van mening dat dit een backwards incompatible wijziging is, we hebben echter toch besloten om de wijziging nu door te voeren binnen de v1 API. De reden hiervoor is dat de gebruiker van de API die nu geen integer meegeeft als perceelnummer geconfronteerd wordt met een 500 error (omdat het perceelnummer in de data een integer is). Als je na de wijziging een string meegeeft krijg je in plaats van de 500 error een 400 error omdat je aanroep niet klopt. Het resultaat is hetzelfde: je krijgt geen daadwerkelijk output, alleen de foutmelding is nu wel duidelijker.

Jasper, op 21 juli heb je aangegeven dat je dit intern zult oppakken. Is dat inmiddels gebeurt? En kun je aangeven of dit er toe zal leiden dat er alsnog een backwards compatible versie van de API beschikbaar zal komen?

Wat ik probeerde aan te geven in mijn post op 21 juli was dat ik jullie verzoek omtrent weglaten of expliciet opnemen van lege velden mee zou geven aan het team dat met de BAG v2 API bezig is.

Zoals ik op 21 julie al aangaf kunnen we de wijziging op dit vlak in de BAG v1 APi niet meer terugdraaien omdat je melding van de ervaren problemen pas 3 weken na de wijziging kwam. Meerdere andere gebruikers van de API hebben een update gedaan van hun implementatie in de tussentijd, zouden we de BAG v1 API nu alsnog backwards compatible maken dan lopen andere partijen wederom tegen problemen aan.

Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.