BAG JSON API request resulteert in XML

Datasets BAG
#1

Het volgende BAG request …

QUERY GET Unexpected XML retry …: {“https://bag.basisregistraties.overheid.nl/api/v1/verblijfsobjecten?page=1&pandrelatering=0213100000075716”,
[
{“Accept”, “application/hal+json”},
{“X-API-Key”, “”}
]}

geeft een XML resultaat …

SEARCH ABORTED …: {%Jason.DecodeError{
data: “<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/”>\n soapenv:Body\n soapenv:Fault\n soapenv:Server\n Policy Falsified\n http://bag.basisregistraties.overheid.nl/api/v1/panden?page=1\n \n <l7:policyResult status=“Assertion Falsified” xmlns:l7=“http://www.weggelaten.com/ws/policy/fault”/>\n \n </soapenv:Fault>\n </soapenv:Body>\n</soapenv:Envelope>\n”,
position: 0,
token: nil
}

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.

#2

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.

#3

Heb de bedrijfsnaam even weg-ge-edit. XML … wat een verschrikkelijk einde :wink:

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?

Prettig weekend voor het overige!

#4

Probleem treedt nog steeds op. Zojuist nog. Mogelijk het quota management dat ingrijpt bij te hoge vraag.

#5

Is het ook nog steeds dezelfde respons die je krijgt?

Als je request dood loopt op de rate limiting staat dat als het goed is aangegeven in de respons.

#6

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!

#7

Ondertussen is bekend in welk deel van de routering de fout optreedt. Wordt morgen verder gekeken of er eind vorige week een fout in is geslopen.

UPDATE 10:00 06-10: Fout is gevonden. Wordt in de loop van de dag opgelost.

#8

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.

#9

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.

#10

Daar wordt al aan gewerkt naar aanleiding van je melding in BAG JSON API call geeft string quota response - BAG - Geoforum

Als je geen XML responses meer krijgt bij een 429 stel ik voor dit topic te sluiten.

#11

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.

#12

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.

#13