Daarnaast worden in dit XML bericht ook details vermeld over gebruik van onderliggende technologie wat je normaal gesproken probeert te voorkomen. Maar, dat is aan jullie.
Er wordt dit weekend onderhoud gepleegd aan de Kadaster infrastructuur. Je request loopt nu ergens dood in die infrastructuur voordat het bij de API komt. Ben bang dat er niks aan te doen is. In theorie zou alles in de loop van de dag weer normaal moeten werken.
Heb de bedrijfsnaam even weg-ge-edit. XML … wat een verschrikkelijk einde
Is het een idee om bij onderhoud tijdelijk een overall API redirect te doen naar een in-onderhoud bericht in het het juiste JSON, XML dan wel HTML formaat?
Exact dezelfde XML response. Ik zie het alleen met hogere load. Vandaar dat ik dacht dat het mogelijk met quota management te maken had. Maar dat laatste is enkel een vermoeden!
Het had inderdaad met de applicatie te maken die de rate limiting verzorgt, en was dus helemaal ongerelateerd aan het onderhoud van afgelopen weekend.
Als het goed is zou je geen XML fouten meer moeten krijgen bij het overschrijden van het max aantal requests per minuut. Mocht je toch nog XML fouten krijgen, hoor ik het graag.
Weten jullie dat er een lege json terugkomt bij quota overschrijding? Mogelijk ten gevolge van het sluiten van de connectie. Krijg de volgende json decode exception …
** (Jason.DecodeError) unexpected end of input at position 0
Dat wordt momenteel geïnterpreteerd als een query overrun. Een HTTP status 429 (te veel requests) gecodeerd in json zou beter zijn.
Ik zal nog wat meer testen. Vooralsnog ziet het er goed uit.
De string quota response lijk ik in mijn laatste test run niet meer te krijgen. Maar voor de zekerheid moet ik mijn code even checken. Dat doe ik morgen.
Wat mij betreft kan je hem sluiten. De status_code 429 komt goed door. Moet wel mijn code aanpassen om de https response beter te testen. Nu gebeurt dat impliciet een stap verder middels een lege json body en vervolgens een json decode exception.