In het kader van het op peil houden van de performance van Locatieserver en als potentiële verbetering voor client-applicaties, zijn wij enkele mogelijkheden om de response body van de suggest-service van Locatieserver aan het onderzoeken. Het betreft de highlighting en de spelling suggesties. Deze zaken worden waarschijnlijk niet door alle afnemers gebruikt, dus het is wellicht beter om deze optioneel te maken. Momenteel wordt de highlighting altijd meegegeven en de spelling-suggesties altijd wanneer een zoekactie minder dan drie resultaten heeft.
In Apache Solr, de onderliggende zoekmachine van Locatieserver, is het mogelijk om deze parameters optioneel te maken. Nu zijn ze nog niet instelbaar. Wanneer ze optioneel zijn, zou er een default-waarde ingesteld kunnen worden door ze niet te tonen. We pogen om zodanige default-waarden te kiezen dat er zoveel mogelijk gebruikers hiervan profijt hebben. Wanneer de default-waarde “on” is voor beide zaken, is deze wijziging niet breaking. Wanneer de default-waarde “off” is, is het wel een breaking change, omdat een client-applicatie dan expliciet in de request-URL moet aangeven om gebruik te blijven maken van de betreffende optie.
Met de highlighting-optie worden de termen gehighlight waarbij een match is op de zoekterm. Stel dat er wordt gezocht op “apeld”, dan begint de highlighting in de request body als volgt:
“highlighting”:{
“gem-0200”:{
“suggest”:[“Gemeente Apeldoorn”]},
“wpl-3560”:{
“suggest”:[“Apeldoorn, Apeldoorn, Gelderland”]},
Je ziet dat in de eerste twee suggesties de term “Apeldoorn” is gehighlight.
Wanneer we de highlight-optie (hl-parameter) optioneel maken en aan laten staan, kunnen clients die hiervan geen gebruik maken “hl=off” meesturen in het request om geen highlighting terug te krijgen. Wanneer we de highlight-optie optioneel maken en standaard uitzetten, moeten alle clients die hiervan gebruik maken “hl=on” meesturen in het request om highlighting terug te krijgen. Dit geldt bijv. voor de PDOK-viewer. In dit typische voorbeeld wordt de response body van 2504 naar 1669 bytes teruggebracht (met indent=on), een besparing van ca. 33%. Met indent=off zijn de getallen 1807 resp. 1116 bytes, een besparing van 38%. De besparingen met een XML-response zijn vergelijkbaar.
Met de spellcheck-optie worden alternatieven getoond wanneer een request drie of minder resultaten oplevert. Stel dat er wordt gezocht op “apeld hofst 110”, dan is de spellcheck als volgt:
“spellcheck”:{
“suggestions”:[
“apeld”,{
“numFound”:2,
“startOffset”:0,
“endOffset”:5,
“suggestion”:[“apeldo”,
“apelk”]},
“hofst”,{
“numFound”:2,
“startOffset”:6,
“endOffset”:11,
“suggestion”:[“hoefst”,
“hoffst”]}],
“collations”:[
“collation”,{
“collationQuery”:“apeldo hofst 110”,
“hits”:1,
“misspellingsAndCorrections”:[
“apeld”,“apeldo”,
“hofst”,“hofst”,
“110”,“110”]}]}}
Wanneer we de spellcheck-optie (spellcheck-parameter) optioneel maken en aan laten staan, kunnen clients die hiervan geen gebruik maken “spellcheck=off” meesturen in het request om geen spelling-suggesties terug te krijgen. Wanneer we de spellcheck-optie optioneel maken en standaard uitzetten, moeten alle clients die hiervan gebruik maken “spellcheck=on” meesturen in het request om deze suggesties terug te krijgen. De PDOK-viewer maakt geen gebruik van deze suggesties. In dit typische voorbeeld wordt de response body van 960 naar 397 bytes teruggebracht (met indent=on), een besparing van maar liefst 58%. Met indent=off zijn de getallen 676 resp. 321 bytes, een besparing van 53%. De besparingen met een XML-response zijn vergelijkbaar.
Juist bij de werking van de suggest-service, waarbij het beoogde gebruik autocomplete-functionaliteit is, is het tonen van deze correcties overkill. Bij het getoonde voorbeeld heeft het ook geen enkele toegevoegde waarde, omdat het duidelijk is dat het gezochte adres “Hofstraat 110, Apeldoorn” is. Aan de andere kant zou een slimme client in bepaalde gevallen on-the-fly correcties kunnen voorstellen, bijv. “utreg” → “utrec”, maar de verwachting is dat het niet eenvoudig is om dit op een goed werkende manier te doen.
Bij deze willen wij aan de lezers van dit bericht vragen hoe zij hierover denken. In het bijzonder willen wij graag weten wat de default-waarde moet worden voor de highlight-optie en wat de default-waarde moet worden voor de spellcheck-optie. Het standaard uitzetten van deze opties is een breaking change, dus dit zullen wij alleen bij de release van een nieuwe versie van Locatieserver implementeren.
. Het is dan natuurlijk wel nadelig voor gebruikers die nu geen gebruik maken van de highlight optie, en hun code dus wel zouden moeten aanpassen, als ze kleinere responses willen. Echter gezien de beperkte grootte van de te behalen winst lijkt het me het niet waard een breaking change door te voeren. Het percentage is misschien hoog, maar als je alleen kijkt naar het aantal bytes lijkt het me nogal verwaarloosbaar.
We nemen dit (met eventuele ander feedback) mee!