De applicatie waar ik aan werk, gebruikt verschillende datasets. O.a. BRT Achtergrondkaart V2 (WMTS) en de “Tiles API” die hoort bij Omgevingsdocumenten verbeelden van Ozon. De applicatie zal regelmatig meerdere keren dezelfde tiles achter elkaar ophalen. Om dat snel te laten gaan, wordt er aan de kant van de applicatie een cache gebruikt.
Dat werkt goed voor BRT (WMTS). In de responses van die service staat deze header:
Maar de responses van de (vector) Tiles API Omgevingsdocumenten worden niet door de cache bewaard. In de responses van die service zie ik geen Cache-Control header.
Is het mogelijk dat de responses van de Tiles API Omgevingsdocumenten ook een Cache-Control header krijgen, of is er een andere manier om de responses te cachen?
Het gaat uiteindelijk om verschillende varianten en omgevingen van Tiles API Omgevingsdocumenten.
Dat lijkt ons een goed idee, bedankt dat je ons hier op wijst.
We zijn de setup van o.a. omgevingsdocumenten aan het herzien en we zullen de Cache-Control header hier in meenemen.
Daarnaast heb ik een ticket op onze backlog gezet om te zien of we Cache-Control header ook op korte termijn kunnen implementeren in de huidige setup.
Voor nu zou je het dus nog even zonder Cache-Control headers moeten doen.
Er is overigens wel een groot verschil tussen de BRT en omgevingsdocumenten. BRT krijgt zo’n 5 keer per jaar een update en omgevingsdocumenten krijgt elke dag een update (en in de toekomst meerdere keren per dag). De cache zal dus een stuk sneller moeten verlopen en de winst zal dus minder groot zijn. Het is dus even de vraag welke waardes de Cache-Control header moet krijgen. Enfin, daar gaan we naar kijken.
Naar verwachting gaat de applicatie steeds binnen een paar minuten requests voor dezelfde tiles doen. Dus ook als de cache de responses maar een paar uur bewaart, zal er winst zijn.