Für Rest-Abfragen, die keine Daten manipulieren (GET), steht ein Caching-Mechanismus zur Verfügung, der für definierte Parameter das Ergebnis einer REST-Page (also des dahinter liegenden Services mit definierten Parametern) zwischenspeichert. Dies ist vor Allem für performancehungrige oder zeitintensiven Abfragen sinnvoll. Um den Mechanismus zu nutzen, muss in der Tabelle Antwortcache lediglich ein Datensatz angelegt werden:
Feld | Beschreibung | Beispielwerte für Service “Karte” | optional |
|---|---|---|---|
Seite | Die REST-Page, für die das Caching definiert wird | nein | |
Parameter | Die Parameter für den Service der REST-Page | id, locale | nein |
Cache-Dauer | Die Dauer, für die der Cache auf Basis des Zeitstempels aktiv ist. Wird | 1 Tag | nein |
Query-Strings | Hier können Werte als Query-Strings definiert werden, für die durch einen Cron-Job der Cache zeitgesteuert vorgeneriert wird | id=1&locale=de_DE | ja |
| Info |
|---|
Hinweis: Query-Strings müssen ohne URL-Encoding gepflegt werden. |
...
In Einzelfällen kann es notwendig sein, den Cache zu umgehen, bspw. um zu überprüfen, ob der Antwortcache aktuell ist. Hierzu kann für alle Services, die per GET aufgerufen werden, der Parameter noCache=1 übergeben werden.
Events
...
Event | Beschreibung |
|---|---|
| Das Event wird beim Ausführen des Cacheaufbaus via Cron-Endpunkt für jeden
Bestehende Subscriber:
|
| Das Event wird beim Ausführen des Cacheaufbaus via Cron-Endpunkt für jeden Query-String aus dem zu Grunde liegenden
Bestehende Subscriber:
|