PDOK biedt voor verschillende datasets (BGT, DKK, en BRT) een download service aan. Bij deze services kan een maatwerk download aangevraagd worden. Gedurende het voorbereiden van deze download is de status opvraagbaar door middel van een speciaal status endpoint. De aanvrager van de download kan hier periodiek een voortgangsindicatie ophalen en voor een gereedstaande download levert een dergelijk verzoek tevens een link naar het klaarstaande bestand op.
Er is gebleken dat een klein aantal aanvragers deze statusinformatie met een erg grote frequentie ophaalt. Dit heeft negatieve gevolgen voor de kwaliteit van de geleverde dienstverlening. PDOK heeft daarom besloten om voor deze verzoeken ârate limitingâ te gaan toepassen. Dit betekent dat aanvragers bij een te groot aantal requests in korte tijd enige tijd geen statusinformatie meer kunnen ophalen. In plaats daarvan zal de service antwoorden met een âHTTP 429 Too Many Requestsâ response. In de API specificatie is deze nieuwe statuscode reeds opgenomen. PDOK is van voornemens om op 15 november 2021 deze rate limiting te activeren, ingesteld op maximaal 60 verzoeken per minuut.
In mijn code had ik al een redelijke wachttijd (in het begin kort, als het langer duurt steeds meer, tot uiteindelijk 1 keer per 30 seconde) ingebouwd gelukkig De 429 code zou dus niet moeten triggeren maar ik zal er een try/catch omheen bouwen.
Maar is het bijhouden van het aantal requests in de afgelopen minuut per download request id niet meer werk dan pas na 1 seconde antwoord geven op het request? Aangenomen dat een client pas een volgende verzoek doet nadat deze een antwoord heeft ontvangen.
Wat natuurlijk ook zou kunnen is het maken van een download optimaliseren, dan zijn ook minder status requests nodig Bij een grote download kan het best lang duren.
Zolang er altijd meer dan een minuut zit tussen request n en request n + 60 zul je nooit tegen een 429 aanlopen. Maar het is natuurlijk altijd verstandig om rekening te houden falende requests.
Deze rate limiting is technisch gezien een stuk minder complex te realiseren dan dat het er van de buitenkant wellicht uit ziet. De impact van (onnodig) langer lopende status requests op onze infrastructuur is groter.
Het sneller maken van de downloads zouden wij zelf ook graag willen. Helaas is het meeste laaghangende fruit reeds lang geleden geplukt.
De 429 code zou dus niet moeten triggeren maar ik zal er een try/catch omheen bouwen.
Bij een grote download kan het best lang duren.