Hallo zusammen,
ich habe mir die Public API und die Doku etwas genauer angesehen und bin dabei über einen Punkt gestolpert, bei dem ich aktuell nicht ganz verstehe, wie der vorgesehene Workflow in der Praxis gedacht ist.
Mir ist bewusst, dass die API offenbar stark auf Integrations-, Import- und Sync-Szenarien ausgelegt ist. Gerade das Shelf-Origin-Pattern ergibt in diesem Kontext auch absolut Sinn. Wenn Daten aus einem Fremdsystem kommen, möchte man natürlich nicht mit internen ResQueServe-IDs im eigenen System arbeiten, sondern mit stabilen externen Referenzen.
Was ich aber beim aktuellen API-Design schwierig finde, ist der Roundtrip aus Sicht eines Clients, der nicht nur Daten hineinschreibt, sondern auch sinnvoll mit bestehenden Daten arbeiten möchte.
Ich nenne hier exemplarisch mal den Bereich POI, das gleiche Verhalten sehe ich aber nach meinem Verständnis genauso bei Units, Keywords und RadioGroups.
Wenn ich eine Liste abrufe, bekomme ich ein Info-Modell zurück, also zum Beispiel PoiInfo.
Wenn ich einen einzelnen Datensatz anhand seiner ID abrufe, bekomme ich ebenfalls wieder nur dieses Info-Modell.
Wenn ich den Datensatz anschließend aktualisieren möchte, erwartet die API für das Update dann aber das eigentliche Domain-Modell, also in diesem Fall Poi.
Und genau an der Stelle frage ich mich, wie dieser Workflow konkret gedacht ist.
Aus Entwicklersicht fühlt sich das unvollständig an. Für einen klassischen Bearbeitungs- oder Integrations-Workflow würde ich erwarten, dass ich einen einzelnen Datensatz auch als vollständiges Objekt laden kann, also in der Form, in der ich ihn bei Bedarf auch wieder zurückschreiben darf. Aktuell scheint es aber eher so zu sein, dass ich aus der API zwar ein abgespecktes Read-Modell bekomme, für das Update aber selbst wieder ein anderes Objekt zusammensetzen muss.
Für ein reines Sync-Szenario, bei dem mein eigenes System ohnehin die führende Datenquelle ist, kann man das noch vertreten. Dann kommt das vollständige Objekt ja aus meiner lokalen Datenbasis und ResQueServe ist eher das Zielsystem. Die API wird aber ja nicht nur für Einweg-Importe beworben, sondern auch für Integrationen in andere Spiele, Tools und externe Anwendungen. Und genau da ergibt diese Einschränkung für mich keinen wirklichen Sinn.
Denn dann stellt sich aus meiner Sicht ganz praktisch die Frage:
- Wie ist der Workflow gedacht, wenn ResQueServe nicht nur Empfänger von Daten ist, sondern ich mit den dort vorhandenen Daten auch weiterarbeiten möchte?
Im Moment wirkt es auf mich so, als gäbe es einen klaren Weg, Daten in das System hineinzuschreiben, aber keinen gleichwertig sauberen Weg, diese Daten wieder in einer Form herauszubekommen, die für Bearbeitung, Roundtrip oder weitergehende Integration geeignet ist.
Deshalb würde mich interessieren, wie der Entwickler sich diese Workflows konkret vorgestellt hat:
-
Ist die Public API bewusst primär als Import- bzw. Sync-Schnittstelle gedacht?
-
Ist es so gewollt, dass man für Updates selbst von Info auf das eigentliche Schreibmodell mappen muss?
-
Gibt es einen vorgesehenen Weg, ein vollständiges Objekt wie Poi, Unit, Keyword oder RadioGroup aus der API zu lesen?
Falls nein, wie sollen dann Anwendungen umgesetzt werden, die nicht nur Daten einspeisen, sondern bestehende Daten auch sinnvoll bearbeiten oder weiterverwenden wollen?
Ich meine das nicht als pauschale Kritik, sondern als ernst gemeinte Frage aus Entwicklersicht. Vielleicht übersehe ich hier auch den beabsichtigten Ansatz.
Im Moment wirkt das API-Design für mich an dieser Stelle aber eher wie ein One-Way-Workflow. Also ein Weg rein, aber kein wirklich sauberer Weg zurück.
Viele Grüße
pat