Veranderingen in bag.basisregistraties.overheid.nl

[Anne]

Sinds vanmorgen 11:40 is er klaarblijkelijk een update uitgevoerd op het endpoint bag.basisregistraties.overheid.nl/api/v1

Waar eerder lege velden niet teruggeleverd werden, worden deze nu expliciet als lege velden teruggegeven. Dat is op zich een verbetering imho, en de nodige aanpassingen zijn snel genoeg doorgevoerd.

Er lijkt echter ook een fout ingeslopen te zijn. Wanneer ik informatie ophaal voor het adres met postcode 7971DN en huisnummer 45 op
https://bag.basisregistraties.overheid.nl/api/v1/verblijfsobjecten/1701010000236047?geldigOp=2020-06-26
en ik vervolgens doorlink naar het bijbehorende pand op
https://bag.basisregistraties.overheid.nl/api/v1/panden/1701100000214590?geldigOp=2020-06-26
en ik vanaf daar een lijst ophaal van de verblijfsobjecten binnen dat pand op
https://bag.basisregistraties.overheid.nl/api/v1/verblijfsobjecten?pandrelatering=1701100000214590?geldigOp=2020-06-26
Krijg ik een lege lijst terug. Dit is echter een twee-onder-een-kap woning, waarvoor ik om 11:35 nog keurig een lijst met twee verblijfsobjecten terugkreeg…

Heb ik een aankondiging gemist?
Is dit een bewuste wijziging?

[RobinTopper]

Ha Anne,

Het backend van de BAG API is inderdaad vanmorgen vervangen.

Probleem dat je nu hebt, komt doordat je beide query parameters vooraf laat gaan door een ?. Dat is alleen correct voor de eerste, de tweede moet een & voor. Zodra je dat doet, krijg je wel weer een verblijfsobject bij het pand terug (nog maar één … ).

Communicatie over de wijzigingen komt nog van @jasperroes

[Anne]

Robin,

Bedankt voor het vlotte antwoord.
Maar het vraagteken staat wel in de url zoals die in het responsebericht staat. Ik bouw deze urls niet zelf op, die komen rechtsreeks uit de json:

..
  "_links" : {
    "verblijfsobjecten" : {
      "href" : "https://bag.basisregistraties.overheid.nl/api/v1/verblijfsobjecten?pandrelatering=1701100000214590?geldigOp=2020-06-26"
    }
...

[RobinTopper]

Dan heb je een bug gevonden. Gaan we meteen naar kijken!

[RobinTopper]

Bug is verholpen. Tweede ? is een & geworden.

[Anne]

Nice. Goed werk.

[Anne]

Eerder beschreven bug is inderdaad verholpen. Bedankt voor de snelle actie.

[Anne]

Helaas lijkt de geoquery op het panden endpoint ook anders afgehandeld te worden dan eerder het geval was.

Op het endpoint https://bag.basisregistraties.overheid.nl/api/v1/panden
Stuur ik de onderstaande JSON in met een POST request:

{"geometrie": {"intersects": {"type": "Polygon", "coordinates": [
  [
    [
      6.236698074,
      52.781676242
    ],
    [
      6.236742659,
      52.78167631
    ],
    [
      6.236742758,
      52.781652368
    ],
    [
      6.236830194,
      52.781652499
    ],
    [
      6.236829956,
      52.781710503
    ],
    [
      6.236829506,
      52.781736245
    ],
    [
      6.236786272,
      52.781736284
    ],
    [
      6.23678615,
      52.781766697
    ],
    [
      6.236697691,
      52.781766564
    ],
    [
      6.236698074,
      52.781676242
    ]
  ]
] } } }

Krijg ik als antwoord:
{“timestamp”:1593182756561,“path”:"/panden",“status”:415,“error”:“Unsupported Media Type”,“message”:"[OpenApi] An Exception occurred [Content type ‘application/json;charset=utf-8’ not supported] resulting in [415] reason [Not supported.]",“requestId”:“a896e435-124942”}

[RobinTopper]

De validatie die we doen op de Content-Type header kan nog niet met de charset informatie omgaan. Hier is een bug voor opgevoerd, maar de fix zal niet meer vandaag komen.

Content-Type = application/json 

Werkt natuurlijk wel

[RobinTopper]

Fix is in productie gezet. Je kan nu weer zonder problemen een Content-type met suffixes opgeven.

Zelfde fix ook meteen voor de Top10NL API in productie gezet.

[Anne]

Mooi. Bedankt!
Zo’n overgang is altijd een moment om de vingers gekruist te houden natuurlijk. Fijn dat jullie er zo snel op reageerden.