Tijdens het bevragen van de BAG krijg ik een JSON format exception op een quota melding in string formaat. Zou deze melding op een JSON API ook niet in JSON teruggegeven worden met een bijbehorend status veld 401 (unauthorized) waarde?
Dit is de melding …
Account plan limit exceeded\r\n\r\nReason: Not Set … quota?failed
Ja, die foutmelding zou inderdaad als JSON teruggegeven moeten worden. We hebben een story op de backlog om dit op te lossen, deze wordt naar verwachting deze of volgende week opgepakt.
Een soortgelijk probleem heb ik met de request …
QUERY POST FAILS ON …: {“https://bag.basisregistraties.overheid.nl/api/v1/panden”,
“{“geometrie”:{“intersects”:{“coordinates”:[[[6.158166441,52.096281914],[6.158163455,52.096281421],[6.1581795,52.096236113],[6.158216104,52.096241294],[6.158560397,52.096290023],[6.158556791,52.096300922],[6.158542911,52.09633889],[6.158411599,52.096321405],[6.158412086,52.096319999],[6.158324802,52.096306584],[6.158325421,52.096305277],[6.158303677,52.096301923],[6.158284689,52.096299333],[6.158200156,52.09628634],[6.158166441,52.096281914]]],“type”:“Polygon”}}}”,
[
{“Accept”, “application/hal+json”},
{“X-API-Key”, "… "}
], [params: [page: 1]]}
die een HTML response 404 levert in trant van …
404 Pagina niet gevonden
Maar de volgende curl …
curl -d “{“geometrie”:{“intersects”:{“coordinates”:[[[6.158166441,52.096281914],[6.158163455,52.096281421],[6.1581795,52.096236113],[6.158216104,52.09624129],[6.158560397,52.096290023],[6.158556791,52.096300922],[6.158542911,52.09633889],[6.158411599,52.096321405],[6.158412086,52.096319999],[6.158324802,52.096306584],[6.158325421,52.096305277],[6.158303677,52.096301923],[6.158284689,52.096299333],[6.158200156,52.09628634],[6.158166441,52.096281914]]],“type”:“Polygon”}}}” -H “Content-Type: application/json” -X POST -H “X-API-KEY: API-Key-weggelaten” -H “Accept: application/hal+json” “https://bag.basisregistraties.overheid.nl/api/v1/panden?page=1”
levert nu wel degelijk een resultaat in JSON af! Naast het HTML resultaat lijkt ook de 404 not found niet terecht!
Ik vermoed dat er ergens een typfout in je request zit, want de API zal nooit een 404 HTML respons geven.
Het feit dat je in curl wel krijgt wat je verwacht, is ook een indicatie dat deze fout niet in de API zit.
De API call zit in een stream en vele voorgangers zijn gewoon goed gegaan. Het is net of er een andere pagina gerenderd wordt. Misschien zegt jullie dit iets meer …
<html dir=\"ltr\" lang=\"nl-NL\"><head> <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\"> <title>404 Pagina niet gevonden</title> <meta content=\"initial-scale=1.0, width=device-width\" name=\"viewport\"> <link href=\"/o/iv-pdok-theme/css/main.css?themeId=ivpdoktheme_WAR_ivpdoktheme\" rel=\"stylesheet\" type=\"text/css\"></head><body class=\"controls-visible basisregistratie-theme yui3-skin-sam guest-site signed-out public-page site\" id=\"senna_surface1\" style=\"background-color: #007395;\"><div id=\"senna_surface1-default\" class=\"flipped\" style=\"display: block;\"><div id=\"wrapper\" class=\"pdok-huisstijl\" style=\" background: #007395;\"> <header id=\"banner\" role=\"banner\"> <div id=\"heading\"></div></header> <section id=\"content\" class=\"container\"><h1 class=\"hide-accessible\">Helaas, deze pagina is niet gevonden</h1> <div class=\"columns-1\" id=\"main-content\" role=\"main\">
Is er misschien een tussenliggende proxy die bij API timeouts het request naar een andere fall-back server routeert?
Dat is de HTML representatie van een 404. Die kan je niet krijgen als je het API basepath of een willekeurig pad daarbinnen opvraagt.
Iets als https://bag.basisregistraties.overheid.nl/panden zal wel zo’n HTML pagina opleveren (geen api/v1/in de URL).
Als je het volledige request met ons kan delen, kunnen we verder kijken. Maar het lijkt er nu erg op dat je niet de URL aanroept die je hierboven gedeeld hebt.
Zou allemaal goed moeten zijn. Wat ik log wordt ook gebruikt bij de API call. Gebruik Elixir library HTTPoison. Zal die vooruit rollen naar een development versie of terug rollen naar een voorgaande. Er was onlangs ook een major upgrade van Erlang naar OTP 23.0.3 Zal die ook terugrollen om zeker te zijn dat de compiler Elixir/Erlang goed is.
Het vreemde is dat ik onlangs alleen maar UI/UX code ontwikkeld heb en niets aan de search engine veranderd heb. Het werkte goed en snel. Zie wel dat er nu quota management ingevoerd is en dat ik het aantal parallelle search threads terug heb moeten brengen. Dat is eigenlijk het enige wat ik heb zien veranderen.
Maar goed. Om zeker te zijn ga ik eerst library, compiler en compiler runtime uitsluiten.
Zoals Robin al aangeeft kunnen we je beter helpen als je ons aan kunt geven welke exacte call je doen.
Ik heb net even wat geprobeerd met de 1e URL die je geef: als ik exact die URL (https://bag.basisregistraties.overheid.nl/api/v1/panden) gebruik krijg ik wat ik ook probeer kwa headers of opbouw van alles achter /api/v1 een valide response, of een JSON foutmelding vanuit de API. Pas zodra ik in het 1e deel van de URL (https://bag.basisregistraties.overheid.nl/api/v1) iets aanpas krijg ik een 404 foutmelding in HTML. Dit hangt er mee samen dat op de https://bag.basisregistraties.overheid.nl URL ook een website draait. Alleen requests die naar een actieve en geldige API gaan komen op de API backend terecht, de rest komt op het CMS uit.
Ben de compiler stap voor stap aan het terugrollen. Zit nog in de OTP 23 range. Volgende stap is naar OTP 22. Dat is een grote release. De HTTPoison library heeft andere problemen gehad met deze overgang. Als de compiler betrouwbaar blijkt duik ik de HTTPoison library in en zal ik de exacte calls tracen.
Ondertussen heb ik geen compiler problemen gevonden. Daarnaast heb ik de HTTPoison library vervangen door Finch. Finch is wat moderner en meer high-performance. Ook weer uitgeprobeerd met diverse compiler versies. Ook dat biedt geen soelaas. Heb zelfs het OS gereset en opnieuw geboot. Ook zonder resultaat. Op onverwachte en zeldzame momenten wordt of de socket gesloten of wordt het API request geforward naar een HTML backend. Hebben jullie misschien een nieuwe Nginx achtige reverse proxy geïnstalleerd of gereconfigureerd? Het lijkt load afhankelijk.
Zie het volgende API request …
QUERY GET FAILS ON …: {“https://bag.basisregistraties.overheid.nl/api/v1/verblijfsobjecten?page=1&pandrelatering=0213100000084035”, [],
[
{“Accept”, “application/hal+json”},
{“X-API-Key”, “API key weggelaten”}
]}
en de onverwachte HTML response waar in dit geval de /api/v1 prefix duidelijk doorkomt …
\n\n404 Not Found\n\nNot Found
\nThe requested URL /api/v1/verblijfsobjecten was not found on this server.
\nAdditionally, a 404 Not Found\nerror was encountered while trying to use an ErrorDocument to handle the request.
\n
Hier zie je dat de /api/v1 prefix wel degelijk door komt!
Zie het verschijnsel sinds ik quota meldingen krijg … Mystère et boul de gomme!!!
Eliminate all other factors, and the one which remains must be the truth.
In mijn voorgaande antwoorden was ik vrij stellig dat de fout eigenlijk niet in de API kon zitten, maar het lijkt erop dat alle andere mogelijke fouten ondertussen uitgesloten zijn … We zullen hier wat verder in moeten duiken. Een request zou niet opeens op een ander backend terecht mogen komen bij een hoge load op het “juiste” backend.
Collega is aan het speuren geweest in de logging van alle routering die nog voor de API zit. Het probleem dat je beschrijft kwam alleen op het verblijfsobjecten endpoint al ~20x per dag voor sinds 1 september. Dat valt samen met een upgrade die die dag is doorgevoerd in één van de routering componenten.
Er is zojuist een nieuwere versie van dat component uitgerold waarin een hele lading bugs is gefixt. Hopelijk is hiermee het probleem verholpen. We zullen het zelf de komende dagen monitoren, maar als je het probleem zelf nog steeds hebt horen we dat ook graag.
Zie nu ook het volgende …
SEARCH ABORTED …: {%Jason.DecodeError{data: “Unable to route to API.”, position: 0, token: nil},
Zou me niet verbazen als er in de API routering misschien één of meerdere servers of down zijn of wat betreft IP adres verkeerd geconfigureerd staan. Draait er een load balancer? Staat de firewall open voor forwarding? Mogelijk dat er in sommige gevallen een catch all is die naar een HTML service routeert?
Omdat het sporadisch en niet structureel optreedt doe ik nu één enkele retry op een gecombineerde actie van zowel HTTPS request als JSON decode. De eerste keer mag één van beiden falen. Maar, de tweede keer moeten beiden lukken. Zo niet dan wordt de search beëindigd.
De retry wordt momenteel niet gelogd. Zal logging toevoegen en dan terugmelden of ik het nog zie gebeuren.
We zien dat het probleem helaas nog steeds optreedt, dus er wordt verder gezocht naar een oplossing.
Ja, ik zie het ook. De gecombineerde retry op een succesvolle HTTPS en een correcte JSON werkt wel goed zolang de errors natuurlijk sporadisch optreden.
Er is mij wat vreemds opgevallen. Het betreft een samengestelde search die BRK v1 Percelen, BAG v1 Panden, BAG v1 Verblijfsobjecten en Ruimtelijke Plannen v3 combineert.
Als ik een search doe uitgaande van BRK v1 Percelen met kadastraleGemeentecode BMN01 dan kan ik hooguit 3 threads parallel laten zoeken voordat het quota management mij om de oren slaat. Resulteert in 25357 API hits in 29 minuten. Is 874 API hits per minuut.
Als ik vervolgens een search doe vanuit BRK v1 Percelen kadastraleGemeentecode ASD16 dan kan ik tot wel 16 threads parallel zoeken! Resulteert in 12223 API hits in 7 minuten. Is 1746 API hits per minuut.
De search parameters zijn wel verschillend maar de API hits laten zich goed vergelijken. Zou dan ook bij hogere belasting op ASD16 verwachten dat het quota management ook zou ingrijpen.
Zijn er misschien verschillende deelsystemen met eigen quota/performance karaketristieken?
Vraag me af of er iets mis is met het quota systeem. Krijg volgende melding …
SEARCH ABORTED …: {%Jason.DecodeError{
data: “Account plan limit exceeded\r\n\r\nReason: Not Set|<eigen API key weggelaten>|<onbekende API Key weggelaten>|quota?failed”,
position: 0,
token: nil
}
Er is zojuist een wijziging doorgevoerd waarmee dit probleem tot het verleden dient te behoren. Het probleem zat in een extern component die niet onder ons beheer valt en was daarnaast lastig te reproduceren. Hierdoor heeft het helaas langer geduurd voordat we een oplossing konden bieden.
Een paar dagen geleden is eindelijk de wijziging doorgevoerd die ervoor zorgt dat alle foutmeldingen als JSON terug komen op de REST APIs van BAG, Top10NL, BRK-DKK, IHR, DUO, RCE, en bestuurlijke grenzen.
Mocht je toch nog niet terug krijgen wat je verwacht, horen we dat graag.