akuckartz
commented
10 years ago Ja, das sollte angesprochen werden. Zumindest für die ersten beiden Versionen wird derartiges kaum zu vermeiden sein. Es wurde bereits einiges getan, um eine hohe Kompatibilität mit der Zukunft zu erreichen. Aber mir sind dabei mehrere Stellen aufgefallen, an denen sich in Zukunft mit erheblicher Wahrscheinlichkeit Änderungen aufdrängen.
Es gibt aber eventuell eine relativ einfache Lösung für die Implementierung. Wenn wir voraussetzen, dass alle Informationen eines OParl 1.0 Endpoints auch in dem neuen ausdrückbar sind, dann kann ein Übersetzer von der neuen zur älteren OParl-Version helfen. Bezüglich des Vokabulars ist der Aufwand für solche Übersetzungen gut überschaubar. Mit SPARQL sollte dafür ein kleiner Satz von CONSTRUCT Statements ausreichen.
Ich nenne das jetzt mal OParl Endpoint ;-)
marians
Das hier wird bestimmt noch mal ein kontroverser Punkt, aber wir müssen das IMHO diskutieren und gut abwägen:
Client-Entwickler, die mit einer bestimmten API*-Endpoint-URL arbeiten, erwarten normalerweise, dass sich die Funktionsweise der API nicht einfach ändert.
Wenn nun ein System auf eine neue OParl-Version aktualisiert wird, können wir nicht garantieren, dass das immer "graceful" abgeht. Also dass ein Client, der für 1.0 programmiert wurde, auch mit der höheren Versionsnummer umgehen kann.
Möchte ein Server-Betreiber die Clients, die mit 1.0 arbeiten, weiter bedienen, muss idealerweise unter der unveränderten URL weiter die 1.0er API arbeiten. Möchte er aber auch die Vorteile einer neuren OParl-Version bieten, muss er unter einer anderen URL einen weiteren Endpoint betreiben.
Mein Wunsch-Szenario:
Beispielstadt launcht im August ihren OParl-Server mit dem Endpunkt
Und dann im Jahr 201X, wenn die neue und doch deutlich veränderte Version fertig ist und der RIS-Anbieter dies ebenfalls anbietet, wir der zusätzliche Endpunkt eröffnet:
Nach einem Jahr dann schaltet Beispielstadt den Endpoint für 1.0 ab bzw. sendet Redirect-Header für alle Zugriffe auf die nun gültigen neuen URLs.
Da das vor allem den Betrieb betrifft und wir es nicht vorschreiben können, ist das natürlich eine Empfehlung. Ich denke aber, dass es sinnvoll ist, diese in der Spec explizit zu beschreiben, damit das von den Betreibern frühzeitig bedacht werden kann.
Als Auswirkung auf unser Specs-Dokument sollten wir alle API-URLs mit Versionsnummer 1.0 im Pfad versehen.
*) Ich nenne es einfach weiter API...