Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 17 Nächste Version anzeigen »

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

optional

Seite

Die REST-Page, für die das Caching definiert wird

nein

Parameter

Die Parameter für den Service der REST-Page

nein

Cache-Dauer

Die Dauer, für die der Cache auf Basis des Zeitstempels aktiv ist

nein

Query-Strings

Hier können Werte als Query-Strings definiert werden, für die durch einen Cron-Job der Cache zeitgesteuert vorgeneriert wird

ja

Hinweis: Query-Strings müssen ohne URL-Encoding gepflegt werden.

Ablauf

Für jeden REST-Request, der per GET im System ankommt, wird die Tabelle Antwortcache geprüft.

  • Existiert ein Eintrag mit übereinstimmender REST-Page und übereinstimmenden Parametern, wird der Cache angewandt.

    • Ist der Cache für die übergebenen Parameter nicht aktiv oder nicht mehr valide (weil der Zeitstempel hinsichtlich der Cache-Dauer abgelaufen ist), wird er neu aufgebaut. Dabei wird auf dem Server eine Datei mit der Antwort des Services für die definierten Parameter abgelegt und mit einem Ablaufdatum versehen, die der definierten Cache-Dauer entspricht.

    • Ist der Cache bereits aufgebaut und valide, wird die dem Cache zu Grunde liegende Datei mit dem Antwortcache ausgelesen und ausgeliefert.

  • Existiert kein passender Eintrag, wird der Request wie üblich beantwortet, indem der zugeordnete Service mit den übergebenen Parametern aufgerufen wird.

Automatischer Aufbau des Caches

Um lange Wartezeiten beim Aufbauen der Caches zu vermeiden, existiert ein Mechanismus, der den Cache für alle Datensätze in der Tabelle Antwortcache automatisch aufbaut.

Der Cron wird wie folgt definiert:

php plugin/remote/brandbox/framework/src/entrypoint.php -endpoint=Cron -package=Join/Restful -host=domain.brandbox.de

Das Cron-Skript holt alle Einträge aus Antwortcache und prüft für jeden gepflegten Parameter-Wert, ob bereits ein Cache existiert. Ist dies nicht der Fall, wird der zu Grunde liegende Service mit den definierten Parameter-Werten aufgerufen und das Ergebnis im Cache gespeichert.

Umgehen des Caches

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

Erasure/Action

Event

Beschreibung

\Brandbox\JoinRestful\Join\Restful\Lib\Event\OnPopulateCachedResponse

Das Event wird beim Ausführen des Cacheaufbaus via Cron-Endpunkt für jeden Antwortcache-Datensatz gefeuert.
Parameter:

  • $cachedResponse: das zu Grunde liegende Antwortcache-Entity

  • $page: die verwendete Seite

  • $profile: das verwendete Mappingprofil

  • $properties: Liste der verwendeten Feldmappings

\Brandbox\JoinRestful\Join\Restful\Lib\Event\OnBuildQueryStringCache

Das Event wird beim Ausführen des Cacheaufbaus via Cron-Endpunkt für jeden Query-String aus dem zu Grunde liegenden Antwortcache-Datensatz gefeuert. Parameter:

  • $cachedResponse: das zu Grunde liegende Antwortcache-Entity

  • $page: die verwendete Seite

  • $parameters: Liste der aus dem Query-String extrahierten Parameter mit Werten (Name-Value-Pairs)

  • $profile: das verwendete Mappingprofil

  • $properties: Liste der verwendeten Feldmappings

  • $queryString: der zu Grunde liegende Query-String

  • $messages: Liste der Nachrichten, die der Cron-Endpunkt für das Cron-Log zurückliefert

  • Keine Stichwörter