Concept for API versioning
Opened this issue · 3 comments
Haben wir hier ein Problem? Solange wir nur unseren BlazorClient unterstützen passt das doch. Wenn wir dazu die API nur erweitern und nicht reduzieren sollten wir doch schon recht Safe sein.
Als mögliche Features werden "System Api tokens for specific parts of the system" und "User Api tokens" genannt. Das weist darauf hin, dass möglicherweise auch externe Clients Teile der API aufrufen. Wenn man die Versionierung aktuell weglässt hat man später folgende Möglichkeiten:
- Nur kompatibel erweitern
- Schnittstellenbrüche einfach akzeptieren
- Versionierung über Header, Query Parameter oder Body Content (bei Posts) hinzufügen. Über die Route geht es nicht mehr --> sonst Bruch der Schnittstelle.
Ist ja als enhancement markiert. Vorerst können wir das auch weglassen.
Als mögliche Features werden "System Api tokens for specific parts of the system" und "User Api tokens" genannt. Das weist darauf hin, dass möglicherweise auch externe Clients Teile der API aufrufen.
Korrekt, folgende Schnittstellen waren da bei mir im Kopf:
- für uns interessant
- zum abrufen von Gameserver configs für Tournaments / Matches
- zum reporten der laufenden Games
- zum reporten von user Stats
- fürs anlegen von support Tickets
- fürs bearbeiten von support Tickets
- für andere zukünftig interessant
- Zeit/ punkte reporting für sport tournaments
Denke mal dass wir für die Stellen wahrscheinlich aber relativ lang mit dem Vorsatz nur kompatibel zu erweitern fahren könnten, aber wenn ich mir die Implementierung anschaue wäre ja sowohl der Ansatz über die URI zu versionieren, als auch der über Header zu versionieren nicht wirklich krasser Aufwand. Von daher könnten wir schon schauen dass wir das vor dem ersten Release, was ja auch noch dauern wird noch mit einbauen. Gäbs aus eurer Sicht Vor- / Nachteile für ne bestimmte Variante?