Mee eens. Zeker als je een zoekservice aanbied die ook buiten je BRK Leverings-abonnementsgebied resultaten moet laten zien, zoals ik aanbied. Ik gebruik daarvoor eerst de locatieserver, als het perceel waar men naar op zoek is daarin voorkomt, doe ik een request naar de DKK-WFS (ook ivm de extra info die daarbij meekomt, zoals de begindatum en zo). Nu doe ik dat op basis van de gemeente, sectie en perceelnummer (en dat werkt prima, overigens), maar op basis van de kadastrale object ID zou mijn filter-xml een stuk eenvoudiger maken.
Overigens merk ik nog wel een dingetje op bij jouw request naar het free-endpoint: Als je rows=1 weglaat, krijg je dit als resultaat:
{
"response":
{
"numFound":797759,
"start":0,
"maxScore":11.290073,
"numFoundExact":true,
"docs":[
{ <snip>
Waarbij de docs-array 9 resultaten bevat! Vanwaar dan die “numFound”:797759 en “numFoundExact”:true? Niet dat het me veel uitmaakt one way or the other, maar het is wel wat apart… Vooral omdat het suggest-endpoint wel netjes “numFound”:1 en “numFoundExact”:true teruggeeft, wat ik bij het free-endpoint ook zou verwachten. Of in ieder geval zou ik bij free verwachten dat numFound=9, hoewel de zoekterm heel specifiek maar 1 resultaat mag opleveren.
