Merge branch 'fix/semver' into 'main'

Adapt API Versioning with semver

See merge request fit-connect/api!52

README.md

@@ -31,6 +31,8 @@ Multiple Resoucen werden im Pfad durch eine Collection-Resource und einer nachfo
 
 Beispiel: `/applications/{applicationId}`
 
-## API-Version taggen
+## Tag API version
 
-    git tag -a v1.0.4 -m "API Version 1.0.4"
+Run and follow the instructions:
+
+    sh tag.sh

docs/apis/delivery-service.mdx

@@ -8,4 +8,4 @@ import VersionDisplay from '@site/src/components/VersionDisplay'
 
 Die aktuell ausgewählte Version der API ist <VersionDisplay artifact={"zustelldienst.yml"}/>.
 
-<ApiSpec specUrl="https://fitko.uber.space/v1.0.0-alpha16/zustelldienst.yml"/>
+<ApiSpec specUrl="https://fitko.uber.space/0.9.0/zustelldienst.yml"/>

docs/details/authentication/cli.md

@@ -2,7 +2,7 @@
 
 Im Folgenden wird beschrieben, wie die OAuth-basierte Authentifizierung mithilfe des FIT-Connect Commandline-Tools funktioniert.
 Dafür werden entweder OAuth-Credentials (Client-ID, Client-Secret) sowie die Adresse des OAuth-Token-Endpunktes oder ein Zugang zum FIT-Connect Developer Portal benötigt.
-Weitere Informationen dazu wie die OAuth-Authentifizierung selbst implementiert werden kann befinden sich in [Authentifizierung von Fachanwendungen](applications) und [Authentifizierung von Usern an Zustelldiensten](users) - außerdem ist hier das Konzept zu [Zustellberechtiungs-Scopes](scopes) zu beachten.
+Weitere Informationen dazu wie die OAuth-Authentifizierung selbst implementiert werden kann befinden sich in [Authentifizierung von Fachanwendungen](./subscriber) und [Authentifizierung von Usern an Zustelldiensten](./sender) - außerdem ist hier das Konzept zu [Zustellberechtiungs-Scopes](./scopes) zu beachten.
 
 ## Installation CLI-Tool
 

docs/getting-started/authentication.mdx

@@ -13,7 +13,7 @@ Da ein Token **max. 24h** gültig ist, muss dieses rechtzeitig erneuert werden.
 Für sendende Systeme reicht der OAuth-Access-Token nicht aus, um Zugriff auf die API zu bekommen.
 Sendende System müssen für den Zugriff auf die API ein User-Token generieren, welches Sie zusammen mit dem Access-Token an die API übermiteln müssen.
 Dieser Access-Token ist mit dem privaten Schlüssel des API Clients zu signieren, der dem öffentlichen Schlüssel des API-Clients entspricht (Siehe [Accountregistrierung](../account)).
-Für Aufbau und Beschreibung des User-Tokens siehe "[Generierung der JWT-Tokens](../details/authentication/users#generierung-der-jwt-tokens)"
+Für Aufbau und Beschreibung des User-Tokens siehe "[Generierung der JWT-Tokens](../details/authentication/sender#generierung-der-jwt-tokens)"
 :::
 
 <Tabs

docs/getting-started/sending/metadata.mdx

@@ -3,7 +3,7 @@ title: Metadaten
 sidebar_position: 5
 ---
 
-Die Antragsmetadaten beschreiben die Struktur der Einreichung und dessen Inhalte, wie beispielsweise Anhänge oder die Fachdaten. Zustätzlich können weitere Informationen über den/die AntragsstellerInnen hinterlegt werden. Eine genaue Definition ist unter XYZ zu finden bzw. direkt im [Schema](https://fitko.uber.space/v1.0.0-alpha15/antragsmetadaten.schema.json) zu finden.
+Die Antragsmetadaten beschreiben die Struktur der Einreichung und dessen Inhalte, wie beispielsweise Anhänge oder die Fachdaten. Zustätzlich können weitere Informationen über den/die AntragsstellerInnen hinterlegt werden. Eine genaue Definition ist unter XYZ zu finden bzw. direkt im [Schema](https://fitko.uber.space/0.9.0/antragsmetadaten.schema.json) zu finden.
 
 Im Folgenden wird nun beschrieben, wie für das Versenden einer Einreichung das Schema aufgebaut und befüllt wird, sowie beim Empfangen einer Einreichung dieser entschlüsselt und gegen das Schema validiert wird.
 

tag.sh

@@ -7,7 +7,7 @@ TAG="$1"
 
 if [ -z "$TAG" ]; then
     echo "Usage: $0 TAG"
-    echo "Example: $0 v1.0.1"
+    echo "Example: $0 1.0.1"
     exit 1
 fi