Veranderingen in bag.basisregistraties.overheid.nl

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?

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

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"
    }
...

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

1 like

Bug is verholpen. Tweede ? is een & geworden.

1 like

Nice. Goed werk.

1 like

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

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ā€}

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

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.

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

1 like

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