BAG API versie 2 en rate limiting

Datasets BAG
#1

Beste BAG API medewerker,

Om onze software alvast voor te bereiden op jullie toekomstige plannen om “Rate limiting” te introduceren, heb ik de vraag hoe ik dan straks aan de volgende gegevens kan komen.

In ons grafisch pakket is het mogelijk een punt te prikken in de kaart en als deze binnen een pand valt, dan

status, contour, huisnummers, straatnamen (ook toekomstige panden)

op te vragen.
Ik heb hiervoor nu een flat genomen in Amersfoort met 67 verblijfsobjecten.
Om alle gewenste informatie op te vragen, doe ik nu 74 bevragingen (en er zijn beslist flats met nog meer verblijfsobjecten):

pand-informatie:
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/panden
requestbody: { “type”: “Point”, “coordinates”: [154984.648,464066.616] }

nummeraanduidingen van dit pand (hij heeft er 67, en krijg er 20 per keer terug):
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/verblijfsobjecten?pandIdentificatie=0307100000324989
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/verblijfsobjecten?pandIdentificatie=0307100000324989&page=2
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/verblijfsobjecten?pandIdentificatie=0307100000324989&page=3
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/verblijfsobjecten?pandIdentificatie=0307100000324989&page=4

Daarna de volgende 67 queries om de huisnummers + huisletters en huisnummertoevoegingen op te halen:
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2//nummeraanduidingen/0307200000380278
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2//nummeraanduidingen/0307200000381497
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2//nummeraanduidingen/0307200000381834
[…]
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2//nummeraanduidingen/0307200000519950
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2//nummeraanduidingen/0307200000520968

En tenslotte de straatnamen, Het betreft een L-vormige flat langs 2 straten (er zijn zelfs panden die aan 4 straten staan):
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/openbareruimten/0307300000307462
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/openbareruimten/0307300000307463

Wat kan ik aan deze bevragingen veranderen als jullie “rate limiting” gaan invoeren? Ik doe dus in heel korte tijd, heel veel bevragingen!

Met vriendelijke groet,
Kees Braaksma

#2

Hallo Kees,
Bedankt voor je vraag.
Het aantal request is sowieso iets, maar misschien wel heel veel te verminderen. Een beetje afhankelijk van je usecase.

Eerst het pand op basis van geometrie. (voor de contour en het pandID)
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/panden
requestbody: { “type”: “Point”, “coordinates”: [154984.648,464066.616] }
(Eventueel met parameter huidig=true om niet ook gesloopte panden te vinden als dat niet nodig is voor je usecase.)

Dan verblijfsobjecten met de pandidentificatie met page size =100 (om de status van het verblijfsobject op te halen)
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/verblijfsobjecten?pandIdentificatie=0307100000324989&pageSize=100

En de adressen met pandidentificatie met page size =100. (Voor de huisnummers en straatnamen)
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/adressen?pandIdentificatie=0307100000324989&pageSize=100

Kanttekening hierbij is dat het adressenendpoint alleen huidige gegevens levert, dus historische adressen worden hier niet teruggegeven. Als het opvragen van de status van het vbo te maken heeft met het huidig zijn van een verblijfsobject en dus adres, zouden de verblijfsobjecten niet meer opgevraagd hoeven te worden. Wil je de specifieke huidige status weten, dan is dat wel nodig.

In dit scenario ben je met 3 requests klaar, voor dit pand met minder dan 101 huidige verblijfsobjecten en adressen.
Meer informatie over de betekenis van huidig: Praktijkhandleiding BAG: Wat is het verschil tussen actieve voorkomens, actuele voorkomens en huidige voorkomens?

Als je wel historie wil, moet je wel de nummeraanduidingen opvragen. Daarbij kan wel direct de straatnaam worden opgevraagd.
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/nummeraanduidingen/0307200000380278?expand=ligtAanOpenbareRuimte

Met dit scenario valt wel iets, maar niet zoveel winst te behalen.

Ratelimiting zal over een minuut worden berekend. Als je in die minuut over de 300 (5*60) bevragingen heengaat, krijg je een ‘strafminuut’. Hij checkt ook pas na een minuut. Bevraag je vanaf het eerste request daarna nog 500 requests binnen die minuut, dan krijg je gewoon antwoord op al je requests. Als je dus heel snel veel bevragingen doet, dan worden allemaal beantwoord. (Serviceproblemen uitgezonderd)

Ik hoop dat dit je helpt,
Groeten Nicole

#3

Hmmm. ALs ik nu als gebruiker even advocaat van de duivel ( :wink: ) ga spelen, dan denk ik ogenblikkelijk: da’s niet handig. Er is dus niks dat mij belet om 8 threads te starten die allemaal 500 requests naar de server gooien (op mijn 4-core laptopje: als ik een 64- of zelfs 128-core server tot mijn beschikking heb…). Als ik dat lekker asynchroon doe, is dat geen enkel probleem.
Ik ben dus bang dat je je server daar niet echt mee beschermt tegen overbevraging…

#4

Meestal kijkt de server niet naar je threads maar naar het aantal requests dat vanaf je client-ip komt. Je kunt de boel overbelasten door de requests van een heleboel verschillende ip’s te laten komen, maar dan moet je meer moeite doen dan software draaien op 1 laptopje. Net zoals je in de fysieke wereld met wat moeite alles stuk kunt maken, kan dat ook in de digitale wereld, maar gelukkig doen de meeste mensen zoiets niet opzettelijk.

1 like
#5

Oh, ik ben het helemaal met je eens. Maar juist dit:

Is een punt. Ik maak zowel professioneel als prive gebruik van FME. Daarmee kan ik http-requests afvuren. En onlangs viel het mij ineens op dat de nieuwste versie dat nu asynchroon kan doen, iets dat mij nog niet eerder was opgevallen. En dat is nou net een dingetje waardoor ik ineens teveel en te snel achter elkaar requests zou kunnen doen, simpelweg omdat ik mijn software heb bijgewerkt naar de laatste versie.
Dat is dan volledig onbewust, maar het resultaat kan wel een overbelaste server zijn, zonder dat ik enige kwaad in de zin heb (integendeel! :wink: ), en misschien zelfs zonder dat ik het in de gaten heb. Als de server dat goed afvangt en mij een nette foutmelding terug stuurt, kan ik er in ieder geval iets aan doen en zit verder niemand anders in de weg.

2 likes
#6

Hallo Nicole,

Hartelijk dank voor je snelle reactie.
Het is ons niet precies duidelijk of onze klanten ook nog informatie van vervallen panden willen hebben.
Ik ga de code in elk geval zodanig aanpassen, dat ik eerst naar bestaand pand zoek en dan de oplossing met weinig requests kan uitvoeren, ligt er alleen een vervallen pand, dan zal op de oude manier de informatie verzameld worden.
Maar daarmee hebben we veel minder kans op bij de limiet van 500 te komen.

Met vriendelijke groet,
Kees

#7

Hallo Nicole,

Welke foutmelding wordt er dan gegeven, als je teveel request doet in een minuut?
Ik heb het zelf even uitgeprobeerd in de testomgeving door 4 keer mijn programma op te starten en dan van 4 grote flats de informatie op te vragen, ik krijg dan:

image
image703×137 5.23 KB

Ik wil er graag een gebruikersvriendelijke melding van maken.

Met vriendelijke groet,
Kees

#8

Hallo Kees,

Vanaf september gaan we beginnen met het stapsgewijs invoeren van een quotum en rate limiting.
Om afnemers ruim de tijd te geven voorbereidingen te treffen voor invoering van de quotum en de rate limiting, hebben wij de implementatie onderverdeeld in de volgende stappen.

Stap 1) 1 september 2022: quotum van 200.000 berichten per dag

Stap 2) 1 december 2022: quotum van 50.000 berichten per dag

Stap 3) 1 maart 2023: rate limiting 5 berichten per seconde

De rate limiting is gewijzigd ten opzichte van de rate limiting waarover wij eind vorig jaar hebben gecommuniceerd. Waar voorheen (in 2021) gekeken werd naar het gemiddelde van het aantal berichten dat er per minuut wordt verzonden, wordt er nu gekeken naar de hoeveelheid berichten dat er per seconde wordt verstuurd. Afnemers worden dus sneller gewezen op het overschrijden van de limiet.

Daarnaast wordt er nu gekeken naar het gebruik per API Key en niet naar het gebruik per IP adres.
Meer informatie over de implementatie van rate limiting is te vinden op Github.

Met vriendelijke groet,

Nathalie Vos
Kadaster BAG