Hallo, ich bin da über eine Logik-Sache gestolpert, bei der ich gerade auf dem Schlauch stehe. Die REST API soll ja eigentlich ohne Mapping-Tabellen auskommen nach Möglichkeit (so interpretiere ich zumindest den Begriff "zustandslos"?). Wenn ich mir die Gambio-Optionen als Beispiel ansehe, dann kann ich den Shop natürlich durchsuchen per API durchsuchen und schauen, ob es die deutschsprachige Option die die Wawi sendet, im Shop schon gibt und wenn ja aktualisieren. Wenn nicht, neu anlegen. Da beißt sich die Katze aber in den Schwanz, denn wenn ich die deutschsprachige Option ändere, kann die natürlich nicht mehr in Gambio gefunden werden und wird dann neu angelegt. Ich habe auch überlegt ob das Feld Admin_label helfen kann, aber das ist ja auch sprachsensibel. Ebenso das Feld description (das man offenbar im Gambio Admin gar nicht anzeigen lassen oder ändern lassen kann, sondern nur über die API?) Wie sollte man idealerweise vorgehen, wenn alle Werte nach denen man suchen kann sich verändern können und ein eindeutiger Identifikator fehlt? Das wäre ja eigentlich die options_id in Gambio, aber die kennt die Warenwirtschaft nicht. Kommt man da irgendwie ohne ein Mapping aus, auch wenn man nicht bei jedem Abgleich alles löschen und neu erstellen möchte? Für den Fall würden die auto_increment Werte sicherlich schnell die Feldgrößen in der Datenbank sprengen?
Zustandslos meint mehr, dass Änderungen immer atomar sind. Atomar bedeutet um von einem Zustand zum nächsten zu kommen braucht es immer nur eine Operation. Das Gegenteil wäre zum Beispiel ich lege ich mit einer Operation eine neue leere Option an und muss dann mit einem zweiten Call einen Namen reinschreiben. Das ist ein noch nicht zuende implementiertes Feature, könnte zu 4.9 kommen: Es geht dort darum weitere Texte zu Optionen hinterlegen zu können, die einem Kunden dann im Frontend angezeigt werden können. Im Moment ist das noch nutzlos. Wir haben also ein paar zukünftige Wünsche an einigen Stellen schon eingezogen. Alle Daten werden als live und dynamisch behandelt, es könnte ja auch sein dass nicht nur eine Quelle auf der API herumschreibt. Ein bisschen Cachen von Inhalten am Ende eines Konsumenten ist nicht immer falsch um nicht immer wieder repetitiv die gleichen Sachen in kurzer Zeit wiederholt nachsehen zu müssen, aber da sollte man haushalten. Dauerhafte, statische Mapping Tabellen sind normal nicht so cool.
Danke, und wie würdest du das mit dem Caching konkret machen am Beispiel von Optionen wie beschrieben?
Die optionId muss man in seiner externen Applikation führen. Sie ist das eindeutige Identifikationsmerkmal. Lässt man sie weg, kann man logischerweise nichts mehr eindeutig identifizieren und steht vor den beschriebenen Problemen. Das ist dann einfach falsch implementiert. Das hat nichts mit Zustandlosigkeit zu tun, wie Wilken schon schrieb.