Het lijkt erop alsof een cross-origin verzoek nog niet helemaal goed werkt. Een OPTIONS verzoek op /locatieserver/search/v3_1/suggest geeft een “405 method not allowed” terug, waardoor verzoeken vanaf een andere origin falen. Zouden jullie dit kunnen repareren?
Het valt mij wel op dat bijv. onderstaande twee requests (zonder parameters) een verschillende response geven, dus het lijkt toch iets meer dan alleen een migratie.
https://geodata.nationaalgeoregister.nl/locatieserver/suggest
https://api.pdok.nl/bzk/locatieserver/search/v3_1/suggest
@nicoburgerhart dat klopt inderdaad. De onderliggende software is ge-upgrade naar de laatste versie. Bovendien valideren we door de nieuwe OpenAPI specificaties de requesten stricter. Hierbij is de q parameter verplicht geworden. Naar ons idee is er geen use-case waarbij de q parameter niet nodig is. Mocht die er wel zijn dan horen we dat graag.
@bartjkdp bedankt voor het melden. De Access-Control-Allow-* headers staan goed, maar de OPTIONS request werkt inderdaad niet meer. We gaan hier direct naar kijken.
Bedankt voor deze toelichting.
Ook al is er een vermoeden dat hier geen use-case voor is, dan nog is het interessant als wijzigingen ook ergens (bijvoorbeeld in zo’n topic als dit) gemeld worden. Er wordt bijvoorbeeld ook gemeld dat XML niet meer mogelijk is als output. Anders moeten ontwikkelaars alles opnieuw uitvinden. Heb het al eens meegemaakt met WFS aanroepen die eerst niet strikt waren en later zomaar wel.
Overigens vind ik het jammer dat XML niet meer mogelijk is want mijn software las dat namelijk uit. Nu wil ik de reden niet betwisten waarom deze keuze gemaakt is, hoewel mijn gevoel zegt dat als er al code ligt om dezelfde data naar XML te exporteren, dat dit niet opnieuw gemaakt hoeft te worden bij de overzetting naar een ander platform.
Overigens ben ik een enorme fan van de locatieserver hoor 
2 likes
@bartjkdp de CORS preflight request gaat nu goed. Dit werkt alleen wanneer de request volgens de http specificaties gedaan wordt, dus met een Origin en Access-Control-Allow-Methods header. Zie voorbeeld:
curl -X OPTIONS -H "Origin: http://example.com" -H "Access-Control-Request-Method: GET" -v https://api.pdok.nl/bzk/locatieserver/search/v3_1/suggest
Onlangs heeft PDOK gecommuniceerd dat de Locatieserver naar het nieuwe platform is gemigreerd (met nieuwe URL’s). Daarbij is gemeld dat XML als output niet meer ondersteund wordt.
Op basis van feedback van gebruikers is echter besloten om dit ook in de nieuwe variant van de Locatieserver weer mogelijk te maken. Naar verwachting zal de XML output volgende week weer beschikbaar zijn. Zodra gereed zal PDOK dit communiceren in deze post op het Geoforum.
4 likes
Top Yvette_PDOK !
Wat fijn PDOK! hier zijn wij heel blij mee.
De XML output functionaliteit voor de nieuwe locatieserver is weer beschikbaar. XML output kan worden opgevraagd met de wt=xml parameter, gelijk aan hoe dat voor de huidige locatieserver is ingericht.
1 like
Toch verbaast het me enigszins hoe zo’n besluit (eerst geen XML en dan weer wel) tot stand komt.
Misschien is dit topic niet de meest logische plek en hoeft zo’n discussie ook niet publiek. Toch zou het fijn zijn als zo’n grote wijziging vooraf wat ruimer onderzocht werd, bijvoorbeeld door een poll of via het panel van het PDOK Ontwikkelteam. Of alvast eerder melden, zodat ontwikkelaars zich erop voor kunnen bereiden.
Heb na de eerste melding een dag uitgetrokken om mijn code om te bouwen, was achteraf dus niet nodig geweest. Heb weer wat geleerd van JSON, zullen we maar zeggen. Deze ervaring zal nu wel meespelen waarom ik toch even wilde reageren op dit besluit
1 like
De verplichte ‘q’ parameter was niet helemaal duidelijk, dank voor de melding.
Wij hebben in onze applicatie een formulier die op dit moment géén gebruik maakt van de q parameter in de /free service. In dit geval is het use-case: formulier met verschillende velden (bv postcode, huisnummer, huisletter etc), waarbij elk veld expliciet in de query wordt toegevoegd met een filter.
Uiteindelijk resulteert dat in het formaat: /free?fq=type:adres&fq=postcode:1122AA&fq=huisnummer:66.
Dit levert goede betrouwbare resultaten op, echter werkt dat niet meer in 3.1.
Is er een mogelijkheid voor deze functionaliteit zonder ‘vrije’ query?
We hebben dit eerlijkheidshalve onderschat. We zagen laag gebruik (o.a. t.o.v. JSON) en omdat er sprake was van nieuwe URL’s (en een half jaar overgangstermijn) leek het een geschikt moment. Excuses en gelukkig dat de investering in JSON niet helemaal voor niks is geweest.
2 likes
We hebben dit intern nog even besproken en voor de /free API is het inderdaad wellicht handig om zonder q parameter te kunnen zoeken. Voor de /suggest laten we hem wel verplicht omdat deze API specifiek voor autocomplete doeleinden bedoeld is. Als de wijziging is doorgevoerd laat ik het weten.
2 likes
De q parameter is niet langer verplicht op het /free endpoint.
1 like
Zojuist even een test gedaan met de oude en nieuwe versie van de free variant.
Oud:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?q=2991HC+and+6&wt=xml&rows=999&plaats=&straatNaam=&huisnummer=6&postcode=2991HC&huisletter=&huisnummertoevoeging=
Nieuw:
https://api.pdok.nl/bzk/locatieserver/search/v3_1/free?q=2991HC+and+6&wt=xml&rows=50
Als ik bij de nieuwe API de velden opneem achter &rows krijg ik een foutmelding. Is dat niet meer toegestaan of niet meer nodig? Overigens geeft de oude versie een hogere score dan de nieuwe.
1 like
Het is bij de nieuwe locatieserver inderdaad niet toegestaan om query parameters op te geven die niet in de OpenAPI specificatie staan. Dat kon bij de oude locatieserver wel, maar deze waren niet nodig.
De scoreberekening tussen de oude en de nieuwe locatieserver is inderdaad anders doordat de onderliggende componenten zijn geüpgraded. Dit zou voor de volgorde van de resultaten in de meeste gevallen niet uit moeten maken. Het kan wel zijn dat voor hele specifieke gevallen dit invloed heeft.
Bedankt voor je antwoord. Maakt het weer een stukje eenvoudiger 
De velden in de responses zijn hetzelfde zag ik. Zijn daar nog aanpassingen gedaan voor het type xml ?
In principe zijn alle velden hetzelfde. Met de parameter fl=* krijg je alle velden terug. Dan zie je dat naast het veld shard het veld shards is toegevoegd. Dit heeft met backwards compatibility te maken.
1 like