OBS/Kostenpflichtige Module/RESTServer - Versionsgeschichte

Rademacker am 19. August 2026 um 12:00 Uhr

2026-08-19T12:00:36Z

← Nächstältere Version		Version vom 19. August 2026, 13:00 Uhr
Zeile 162:		Zeile 162:
	Eigenschaften:		Eigenschaften:

	* '''Abmelden wirkt sofort.''' Ein Endpunkt~~-Skript~~ sperrt die ~~laufende~~ Sitzung ~~mit einem einzigen Antwortfeld (''_OBS_JWT_REVOKE'')~~; alle Token dieser Sitzung sind damit unmittelbar ungültig, auch die noch nicht abgelaufenen.		* '''Abmelden wirkt sofort.''' Ein ''DELETE'' auf den JWT-Endpunkt sperrt die Sitzung; alle Token dieser Sitzung sind damit unmittelbar ungültig, auch die noch nicht abgelaufenen. Anmelden, Erneuern und Abmelden laufen also über einen einzigen Endpunkt, und für das Abmelden ist kein Skript nötig.
	* '''Ein Refresh-Token gilt genau einmal.''' Beim Erneuern wird es entwertet. Wird es später erneut vorgelegt, gilt das als Diebstahl oder Fehlfunktion: die betroffene Sitzung wird komplett gesperrt und der Vorfall protokolliert.		* '''Ein Refresh-Token gilt genau einmal.''' Beim Erneuern wird es entwertet. Wird es später erneut vorgelegt, gilt das als Diebstahl oder Fehlfunktion: die betroffene Sitzung wird komplett gesperrt und der Vorfall protokolliert.
	* '''Alle Geräte abmelden.''' ~~Über dasselbe Feld lassen sich~~ auch alle Sitzungen eines Benutzers sperren - der Support-Fall „Gerät verloren".		* '''Alle Geräte abmelden.''' Ein gewöhnlicher Endpunkt kann über das Antwortfeld ''_OBS_JWT_REVOKE'' auch alle Sitzungen eines Benutzers sperren - der Support-Fall „Gerät verloren".

	{{Achtung\|Mit der Einführung dieser Prüfung verlieren '''alle vorher		{{Achtung\|Mit der Einführung dieser Prüfung verlieren '''alle vorher

Rademacker am 19. August 2026 um 10:13 Uhr

2026-08-19T10:13:38Z

@@ Zeile 85: / Zeile 85: @@
 |-
 | Idempotenz   || RESTSRV_IDEMPOTENCY  || Speicher für Idempotency-Keys und die dazu gelieferte Antwort
 |-
 | Protokoll    || RESTSRV_PROTO        || Laufende Ereignisse, Fehler, Audit-Einträge
@@ Zeile 96: / Zeile 98: @@
 # Authentifizierung über den API-Key (Header ''apikey'')
 # CORS-Prüfung (sofern ''Origin''-Header gesetzt)
-# Optional: JWT-Prüfung (sofern für den Zugang aktiviert)
+# Optional: JWT-Prüfung - Signatur, Ablauf und Sitzung (sofern für den Zugang aktiviert)
 # Routing: Auflösung des Pfads über die Pfad-Templates der Endpunkte
 # Prüfung der Berechtigung (Zugang -> Endpunkt)
@@ Zeile 148: / Zeile 150: @@
 Details und die Statuscodes: [[OBS/Kostenpflichtige Module/RESTServer/Scripting|Scripting]].
 ==Fehlerformat==
@@ Zeile 186: / Zeile 211: @@
 * '''Body-Limit:''' max. 10 MB Request-Body (JSON), max. 1024 Zeichen pro Header- oder Query-Parameter. Datei-Uploads laufen über einen separaten Pfad und sind pro Endpunkt auf <code>re_upload_size</code> MB begrenzt (Standard 25&nbsp;MB).
 * '''Sensible Felder''' (''password'', ''token'', ''secret'', ''apikey'', ''authorization'', ''cookie'', ...) werden in Protokoll-Ausgaben automatisch maskiert.
 * '''Reserviertes Präfix:''' Parameter-Namen mit Präfix ''_OBS_'' können von aussen nicht gesetzt werden, sie sind für den Server reserviert (z.B. JWT-Claims).
 * '''Geblockte Header:''' ''authorization'', ''cookie'', ''proxy-authorization'', ''x-forwarded-for'', ''x-real-ip'', ''apikey'', ''api_key'' werden nicht an das Skript durchgereicht.

Rademacker: /* Fehlerformat */

2026-08-18T06:02:45Z

Fehlerformat

← Nächstältere Version		Version vom 18. August 2026, 07:02 Uhr
Zeile 156:		Zeile 156:
	<pre>		<pre>
	{		{



	"error": {		"error": {
	"code": "AUTH_EXPIRED",		"code": "AUTH_EXPIRED",

Rademacker am 18. August 2026 um 06:02 Uhr

2026-08-18T06:02:12Z

← Nächstältere Version		Version vom 18. August 2026, 07:02 Uhr
Zeile 151:		Zeile 151:
	==Fehlerformat==		==Fehlerformat==

	Jede Fehlerantwort des Servers hat dieselbe Form~~. Neben den bisherigen Feldern~~		Jede Fehlerantwort des Servers hat dieselbe Form: ein einziges ''error''-Objekt
	~~steht~~ ein ''error''-Objekt mit maschinenlesbarem Code, Meldung und Korrelations-ID:		mit maschinenlesbarem Code, Support-Kennung, Meldung und Korrelations-ID:

	<pre>		<pre>
	{		{
	~~"Fehlercode": "Y00E2RTPDY",~~
	~~"Nachricht": "Ungültiges oder abgelaufenes Token",~~
	~~"traceId": "20260817T091233123-00001A",~~
	"error": {		"error": {
	"code": "AUTH_EXPIRED",		"code": "AUTH_EXPIRED",
			"uid": "Y00E2RTPDY",
	"message": "Ungültiges oder abgelaufenes Token",		"message": "Ungültiges oder abgelaufenes Token",
	"traceId": "20260817T091233123-00001A"		"traceId": "20260817T091233123-00001A"
Zeile 167:		Zeile 168:
	</pre>		</pre>

	~~Die Felder ''Fehlercode'~~' ~~und ''Nachricht'' bleiben erhalten - bestehende~~		* '''code''' - sprechender Bezeichner (z.B. ''AUTH_EXPIRED'', ''NOT_FOUND'', ''RATE_LIMITED'', ''INTERNAL_ERROR''), an dem ein Client seine Reaktion festmachen kann, ohne Texte auszuwerten.
	~~Konsumenten müssen nicht angepasst werden. Der~~ ''code'~~' im ''error~~''-~~Objekt ist~~		* '''uid''' - OBS-Kennung der Codestelle. Für die Support-Recherche gedacht, nicht zur Auswertung im Client.
	~~ein~~ sprechender Bezeichner (z.B. ''AUTH_EXPIRED'', ''NOT_FOUND'',		* '''message''' - Text für den Client. Interne Fehlerdetails stehen nie darin, sondern ausschliesslich im Protokoll '''RESTSRV_PROTO'''.
	''RATE_LIMITED'', ''INTERNAL_ERROR''), an dem ein Client seine Reaktion		* '''traceId''' - Korrelations-ID. Steht zusätzlich im Header ''X-Trace-Id'' und in jeder zugehörigen Logzeile.
	festmachen kann, ohne Texte auszuwerten. Ein Endpunkt-Skript kann eigene Codes
	setzen; siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].		Ein Endpunkt-Skript kann eigene Codes setzen; siehe
			[[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

			{{Achtung\|Früher standen ''Fehlercode'', ''Nachricht'' und ''traceId'' zusätzlich
			flach neben dem ''error''-Objekt. Diese Felder sind entfallen - der Wert von
			''Fehlercode'' heisst jetzt ''error.uid'', ''Nachricht'' entspricht
			''error.message''. Clients, die die flachen Felder auswerten, müssen angepasst
			werden.}}

	==Sicherheitsmerkmale==		==Sicherheitsmerkmale==

Rademacker am 17. August 2026 um 06:48 Uhr

2026-08-17T06:48:48Z

← Nächstältere Version		Version vom 17. August 2026, 07:48 Uhr
Zeile 83:		Zeile 83:
	\|-		\|-
	\| Berechtigung \|\| RESTSRV_ACCESS \|\| Verbindet Zugang und Endpunkt		\| Berechtigung \|\| RESTSRV_ACCESS \|\| Verbindet Zugang und Endpunkt
			\|-
			\| Idempotenz \|\| RESTSRV_IDEMPOTENCY \|\| Speicher für Idempotency-Keys und die dazu gelieferte Antwort
	\|-		\|-
	\| Protokoll \|\| RESTSRV_PROTO \|\| Laufende Ereignisse, Fehler, Audit-Einträge		\| Protokoll \|\| RESTSRV_PROTO \|\| Laufende Ereignisse, Fehler, Audit-Einträge
Zeile 91:		Zeile 93:
	Eine Anfrage durchläuft folgende Stationen:		Eine Anfrage durchläuft folgende Stationen:

	# Rate-Limit-Prüfung (pro API-Key bzw. IP und global)		# Rate-Limit-Prüfung (pro API-Key bzw. IP und global, Schwellen je Server-Profil)
	# Authentifizierung über den API-Key (Header ''apikey'')		# Authentifizierung über den API-Key (Header ''apikey'')
	# CORS-Prüfung (sofern ''Origin''-Header gesetzt)		# CORS-Prüfung (sofern ''Origin''-Header gesetzt)
Zeile 97:		Zeile 99:
	# Routing: Auflösung des Pfads über die Pfad-Templates der Endpunkte		# Routing: Auflösung des Pfads über die Pfad-Templates der Endpunkte
	# Prüfung der Berechtigung (Zugang -> Endpunkt)		# Prüfung der Berechtigung (Zugang -> Endpunkt)
			# Idempotenz-Prüfung (nur bei POST/PUT/PATCH/DELETE '''mit''' ''Idempotency-Key''-Header)
	# Ausführung des Endpunkt-Skripts (oder WebHook-Antwort)		# Ausführung des Endpunkt-Skripts (oder WebHook-Antwort)
			# Festschreiben des Ergebnisses im Idempotenz-Speicher (sofern in Schritt 7 reserviert)
	# JSON-Antwort, Statistik-Eintrag, Protokoll-Eintrag		# JSON-Antwort, Statistik-Eintrag, Protokoll-Eintrag

Zeile 128:		Zeile 132:
	Verarbeitung (z.B. DMS-Ablage) übernimmt das Skript. Details:		Verarbeitung (z.B. DMS-Ablage) übernimmt das Skript. Details:
	[[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].		[[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

			==Doppelte Sendungen abfangen (Idempotenz)==

			Ein Client, der nach einem Timeout dieselbe Anfrage erneut schickt, darf keine
			Zweitbuchung auslösen. Der Server erledigt das selbst: Sendet ein Aufruf mit
			'''POST''', '''PUT''', '''PATCH''' oder '''DELETE''' den Header
			<code>Idempotency-Key</code>, merkt sich der Server Schlüssel und Ergebnis in
			'''RESTSRV_IDEMPOTENCY'''. Eine Wiederholung mit demselben Schlüssel und demselben
			Inhalt bekommt die '''gespeicherte Antwort''' zurück - das Endpunkt-Skript läuft
			gar nicht erst an.

			* '''Ohne den Header ändert sich nichts.''' Bestehende Endpunkte verhalten sich unverändert.
			* '''Kein Schalter am Endpunkt.''' Die Mechanik greift automatisch, sobald der Header anliegt.
			* '''Das Skript muss nichts tun.''' Eine eigene Idempotenz-Logik im Skript ist nicht mehr nötig.

			Details und die Statuscodes: [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

			==Fehlerformat==

			Jede Fehlerantwort des Servers hat dieselbe Form. Neben den bisherigen Feldern
			steht ein ''error''-Objekt mit maschinenlesbarem Code, Meldung und Korrelations-ID:

			<pre>
			{
			"Fehlercode": "Y00E2RTPDY",
			"Nachricht": "Ungültiges oder abgelaufenes Token",
			"traceId": "20260817T091233123-00001A",
			"error": {
			"code": "AUTH_EXPIRED",
			"message": "Ungültiges oder abgelaufenes Token",
			"traceId": "20260817T091233123-00001A"
			}
			}
			</pre>

			Die Felder ''Fehlercode'' und ''Nachricht'' bleiben erhalten - bestehende
			Konsumenten müssen nicht angepasst werden. Der ''code'' im ''error''-Objekt ist
			ein sprechender Bezeichner (z.B. ''AUTH_EXPIRED'', ''NOT_FOUND'',
			''RATE_LIMITED'', ''INTERNAL_ERROR''), an dem ein Client seine Reaktion
			festmachen kann, ohne Texte auszuwerten. Ein Endpunkt-Skript kann eigene Codes
			setzen; siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

	==Sicherheitsmerkmale==		==Sicherheitsmerkmale==

	Der REST-Server enthält eine Reihe ~~fest verdrahteter~~ Schutzmechanismen:		Der REST-Server enthält eine Reihe von Schutzmechanismen:

	* '''Rate-Limit:''' max. 10 fehlgeschlagene und 120 erfolgreiche Anfragen pro API-Key (Account) bzw. IP und 60 Sekunden, max. 600 Anfragen global pro 60 Sekunden. Beim Überschreiten wird HTTP 429 mit ''Retry-After''-Header zurückgegeben. Die Schwellen ~~sind serverseitig konfigurierbar~~.		* '''Rate-Limit:''' Standardmässig max. 10 fehlgeschlagene und 120 erfolgreiche Anfragen pro API-Key (Account) bzw. IP und 60 Sekunden, max. 600 Anfragen global pro 60 Sekunden. Beim Überschreiten wird HTTP 429 mit ''Retry-After''-Header zurückgegeben. Die vier Schwellen lassen sich '''pro Server-Profil''' hinterlegen; die Zähler laufen ebenfalls getrennt je Profil, ein überlastetes Profil bremst das andere also nicht mit aus. Siehe [[OBS/Kostenpflichtige Module/RESTServer/Server-Profile\|Server-Profile]].
	* '''Body-Limit:''' max. 10 MB Request-Body (JSON), max. 1024 Zeichen pro Header- oder Query-Parameter. Datei-Uploads laufen über einen separaten Pfad und sind pro Endpunkt auf <code>re_upload_size</code> MB begrenzt (Standard 25 MB).		* '''Body-Limit:''' max. 10 MB Request-Body (JSON), max. 1024 Zeichen pro Header- oder Query-Parameter. Datei-Uploads laufen über einen separaten Pfad und sind pro Endpunkt auf <code>re_upload_size</code> MB begrenzt (Standard 25 MB).
	* '''Sensible Felder''' (''password'', ''token'', ''secret'', ''apikey'', ''authorization'', ''cookie'', ...) werden in Protokoll-Ausgaben automatisch maskiert.		* '''Sensible Felder''' (''password'', ''token'', ''secret'', ''apikey'', ''authorization'', ''cookie'', ...) werden in Protokoll-Ausgaben automatisch maskiert.
Zeile 144:		Zeile 189:
	==Protokoll==		==Protokoll==

	Die Tabelle '''RESTSRV_PROTO''' enthält alle relevanten Ereignisse: erfolgreiche und abgelehnte Anfragen, TLS-/JWT-Fehler, Bindungs-Ereignisse, Skript-Fehler. Einträge sind nach Datum, Uhrzeit und Host (IP oder Account-Name) sortiert. Das Protokoll ist die erste Anlaufstelle bei Störungen. Jede Antwort ~~trÄgt~~ zudem eine Korrelations-ID (Response-Header ''X-Trace-Id''), die in den Protokoll-~~EintrÄgen~~ wiederzufinden ist.		Die Tabelle '''RESTSRV_PROTO''' enthält alle relevanten Ereignisse: erfolgreiche und abgelehnte Anfragen, TLS-/JWT-Fehler, Bindungs-Ereignisse, Skript-Fehler. Einträge sind nach Datum, Uhrzeit und Host (IP oder Account-Name) sortiert. Das Protokoll ist die erste Anlaufstelle bei Störungen. Jede Antwort trägt zudem eine Korrelations-ID (Response-Header ''X-Trace-Id''), die in den Protokoll-Einträgen wiederzufinden ist.

	==Statistik==		==Statistik==
Zeile 174:		Zeile 219:
	* [[OBS/Kostenpflichtige Module/RESTServer/Endpunkte\|Endpunkte]] - Verwaltung, Berechtigungen, WebHooks		* [[OBS/Kostenpflichtige Module/RESTServer/Endpunkte\|Endpunkte]] - Verwaltung, Berechtigungen, WebHooks
	* [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]] - Aufbau der Endpunkt-Skripte		* [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]] - Aufbau der Endpunkt-Skripte
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel1\|Beispiel: Daten-Abruf mit JWT]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel1\|Beispiel 1: Daten-Abruf mit JWT]]
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel2\|Beispiel: Datensatz anlegen mit JSON-Body]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel2\|Beispiel 2: Zeiterfassung als komplette Webanwendung]]
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel: Pfad-Parameter im Routing]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel3\|Beispiel 3: Datensatz anlegen mit JSON-Body (CRUD)]]
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel5\|Beispiel: Schreibzugriff mit Statuscodes, ETag und Idempotenz]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel 4: Pfad-Parameter im Routing]]
			* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel5\|Beispiel 5: Schreibzugriff mit Statuscodes, ETag und Idempotenz]]
			* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel6\|Beispiel 6: Datei-Upload und Ablage im DMS]]

Rademacker am 30. Juni 2026 um 10:54 Uhr

2026-06-30T10:54:38Z

← Nächstältere Version		Version vom 30. Juni 2026, 11:54 Uhr
Zeile 117:		Zeile 117:

	Der Server akzeptiert die Methoden '''GET''', '''POST''', '''PUT''', '''DELETE''' und '''PATCH''' sowie '''OPTIONS''' (CORS-Preflight, ohne Skript-Aufruf). Jede Methode wird im Endpunkt-Skript als gleichnamige Funktion implementiert. Siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].		Der Server akzeptiert die Methoden '''GET''', '''POST''', '''PUT''', '''DELETE''' und '''PATCH''' sowie '''OPTIONS''' (CORS-Preflight, ohne Skript-Aufruf). Jede Methode wird im Endpunkt-Skript als gleichnamige Funktion implementiert. Siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

			==Datei-Uploads==

			Endpunkte, die dafür freigeschaltet sind (<code>re_upload</code>), nehmen Dateien
			per <code>multipart/form-data</code> oder als fortsetzbaren '''Resumable-Upload'''
			(<code>Content-Range</code>) entgegen. Die maximale Grösse wird pro Endpunkt
			festgelegt (<code>re_upload_size</code>, Standard 25 MB); Überschreitung
			ergibt 413, ein Upload an einen nicht freigeschalteten Endpunkt 415. Der Server
			legt die Datei temporär ab und übergibt dem Skript den Pfad; die weitere
			Verarbeitung (z.B. DMS-Ablage) übernimmt das Skript. Details:
			[[OBS/Kostenpflichtige Module/RESTServer/Scripting\|Scripting]].

	==Sicherheitsmerkmale==		==Sicherheitsmerkmale==
Zeile 123:		Zeile 134:

	* '''Rate-Limit:''' max. 10 fehlgeschlagene und 120 erfolgreiche Anfragen pro API-Key (Account) bzw. IP und 60 Sekunden, max. 600 Anfragen global pro 60 Sekunden. Beim Überschreiten wird HTTP 429 mit ''Retry-After''-Header zurückgegeben. Die Schwellen sind serverseitig konfigurierbar.		* '''Rate-Limit:''' max. 10 fehlgeschlagene und 120 erfolgreiche Anfragen pro API-Key (Account) bzw. IP und 60 Sekunden, max. 600 Anfragen global pro 60 Sekunden. Beim Überschreiten wird HTTP 429 mit ''Retry-After''-Header zurückgegeben. Die Schwellen sind serverseitig konfigurierbar.
	* '''Body-Limit:''' max. 10 MB Request-Body, max. 1024 Zeichen pro Header- oder Query-Parameter.		* '''Body-Limit:''' max. 10 MB Request-Body (JSON), max. 1024 Zeichen pro Header- oder Query-Parameter. Datei-Uploads laufen über einen separaten Pfad und sind pro Endpunkt auf <code>re_upload_size</code> MB begrenzt (Standard 25 MB).
	* '''Sensible Felder''' (''password'', ''token'', ''secret'', ''apikey'', ''authorization'', ''cookie'', ...) werden in Protokoll-Ausgaben automatisch maskiert.		* '''Sensible Felder''' (''password'', ''token'', ''secret'', ''apikey'', ''authorization'', ''cookie'', ...) werden in Protokoll-Ausgaben automatisch maskiert.
	* '''Reserviertes Präfix:''' Parameter-Namen mit Präfix ''_OBS_'' können von aussen nicht gesetzt werden, sie sind für den Server reserviert (z.B. JWT-Claims).		* '''Reserviertes Präfix:''' Parameter-Namen mit Präfix ''_OBS_'' können von aussen nicht gesetzt werden, sie sind für den Server reserviert (z.B. JWT-Claims).

Rademacker am 29. Juni 2026 um 10:08 Uhr

2026-06-29T10:08:37Z

← Nächstältere Version		Version vom 29. Juni 2026, 11:08 Uhr
Zeile 91:		Zeile 91:
	Eine Anfrage durchläuft folgende Stationen:		Eine Anfrage durchläuft folgende Stationen:

	# Rate-Limit-Prüfung (pro IP und global)		# Rate-Limit-Prüfung (pro API-Key bzw. IP und global)
	# Authentifizierung über den API-Key (Header ''apikey'')		# Authentifizierung über den API-Key (Header ''apikey'')
	# CORS-Prüfung (sofern ''Origin''-Header gesetzt)		# CORS-Prüfung (sofern ''Origin''-Header gesetzt)
Zeile 122:		Zeile 122:
	Der REST-Server enthält eine Reihe fest verdrahteter Schutzmechanismen:		Der REST-Server enthält eine Reihe fest verdrahteter Schutzmechanismen:

	* '''Rate-Limit:''' max. 10 fehlgeschlagene und 120 erfolgreiche Anfragen pro IP und 60 Sekunden, max. 600 Anfragen global pro 60 Sekunden. Beim Überschreiten wird HTTP 429 zurückgegeben.		* '''Rate-Limit:''' max. 10 fehlgeschlagene und 120 erfolgreiche Anfragen pro API-Key (Account) bzw. IP und 60 Sekunden, max. 600 Anfragen global pro 60 Sekunden. Beim Überschreiten wird HTTP 429 mit ''Retry-After''-Header zurückgegeben. Die Schwellen sind serverseitig konfigurierbar.
	* '''Body-Limit:''' max. 10 MB Request-Body, max. 1024 Zeichen pro Header- oder Query-Parameter.		* '''Body-Limit:''' max. 10 MB Request-Body, max. 1024 Zeichen pro Header- oder Query-Parameter.
	* '''Sensible Felder''' (''password'', ''token'', ''secret'', ''apikey'', ''authorization'', ''cookie'', ...) werden in Protokoll-Ausgaben automatisch maskiert.		* '''Sensible Felder''' (''password'', ''token'', ''secret'', ''apikey'', ''authorization'', ''cookie'', ...) werden in Protokoll-Ausgaben automatisch maskiert.
Zeile 133:		Zeile 133:
	==Protokoll==		==Protokoll==

	Die Tabelle '''RESTSRV_PROTO''' enthält alle relevanten Ereignisse: erfolgreiche und abgelehnte Anfragen, TLS-/JWT-Fehler, Bindungs-Ereignisse, Skript-Fehler. Einträge sind nach Datum, Uhrzeit und Host (IP oder Account-Name) sortiert. Das Protokoll ist die erste Anlaufstelle bei Störungen.		Die Tabelle '''RESTSRV_PROTO''' enthält alle relevanten Ereignisse: erfolgreiche und abgelehnte Anfragen, TLS-/JWT-Fehler, Bindungs-Ereignisse, Skript-Fehler. Einträge sind nach Datum, Uhrzeit und Host (IP oder Account-Name) sortiert. Das Protokoll ist die erste Anlaufstelle bei Störungen. Jede Antwort trÄgt zudem eine Korrelations-ID (Response-Header ''X-Trace-Id''), die in den Protokoll-EintrÄgen wiederzufinden ist.

	==Statistik==		==Statistik==
Zeile 166:		Zeile 166:
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel2\|Beispiel: Datensatz anlegen mit JSON-Body]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel2\|Beispiel: Datensatz anlegen mit JSON-Body]]
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel: Pfad-Parameter im Routing]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel: Pfad-Parameter im Routing]]
			* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel5\|Beispiel: Schreibzugriff mit Statuscodes, ETag und Idempotenz]]

Rademacker am 15. Juni 2026 um 07:31 Uhr

2026-06-15T07:31:07Z

← Nächstältere Version		Version vom 15. Juni 2026, 08:31 Uhr
Zeile 95:		Zeile 95:
	# CORS-Prüfung (sofern ''Origin''-Header gesetzt)		# CORS-Prüfung (sofern ''Origin''-Header gesetzt)
	# Optional: JWT-Prüfung (sofern für den Zugang aktiviert)		# Optional: JWT-Prüfung (sofern für den Zugang aktiviert)
	# Auflösung ~~von Endpunkt / Sub~~-~~URL / Version~~		# Routing: Auflösung des Pfads über die Pfad-Templates der Endpunkte
	# Prüfung der Berechtigung (Zugang -> Endpunkt)		# Prüfung der Berechtigung (Zugang -> Endpunkt)
	# Ausführung des Endpunkt-Skripts (oder WebHook-Antwort)		# Ausführung des Endpunkt-Skripts (oder WebHook-Antwort)
Zeile 102:		Zeile 102:
	==Adressierung==		==Adressierung==

	Ein Endpunkt wird über ~~drei Bestandteile~~ angesprochen~~: Endpunkt-Name~~, ~~optionale Sub-URL~~ und ~~Version~~:		Ein Endpunkt wird über ein '''Pfad-Template''' angesprochen, das den Pfad nach dem Host beschreibt und Platzhalter enthalten kann:

	http://[Hostadresse][:Port]/[~~Endpunkt][/Sub~~-~~URL]/[Version~~]		http://[Hostadresse][:Port][Pfad-Template]

	Beispiele:		Beispiele:

	https://api.meinserver.de/kalender/v1		https://api.meinserver.de/kalender/v1
	https://api.meinserver.de/~~email~~/~~mein_konto/v1.0~~		https://api.meinserver.de/orders/{uid}
	https://api.meinserver.de/~~zeiterfa~~/~~mobile~~/v2		https://api.meinserver.de/orders/{uid}/modules/{code}

	~~Durch die Versionierung kann~~ eine ~~Endpunkt-~~Funktionalität ~~verändert werden~~, ohne bestehende Konsumenten zu brechen.		Statische Segmente müssen exakt passen; Platzhalter in geschweiften Klammern (z.B. {uid}) matchen einen beliebigen Wert und stehen im Skript als Pfad-Parameter zur Verfügung. Eine Versionskennung wird als statisches Segment ins Template aufgenommen (z.B. /kalender/v1), um eine Funktionalität zu verändern, ohne bestehende Konsumenten zu brechen. Details: [[OBS/Kostenpflichtige Module/RESTServer/Endpunkte\|Endpunkte]].

	==Unterstützte HTTP-Methoden==		==Unterstützte HTTP-Methoden==
Zeile 165:		Zeile 165:
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel1\|Beispiel: Daten-Abruf mit JWT]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel1\|Beispiel: Daten-Abruf mit JWT]]
	* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel2\|Beispiel: Datensatz anlegen mit JSON-Body]]		* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel2\|Beispiel: Datensatz anlegen mit JSON-Body]]
			* [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel: Pfad-Parameter im Routing]]

Rademacker am 19. Mai 2026 um 06:39 Uhr

2026-05-19T06:39:34Z

← Nächstältere Version		Version vom 19. Mai 2026, 07:39 Uhr
Zeile 19:		Zeile 19:

	Die folgenden Einsatzfälle sind typische Beispiele, an denen sich der praktische Nutzen ablesen lässt. Es ist keine abschliessende Liste - alles, was sich in OBS-Skripten abbilden lässt, kann auch über einen Endpunkt bereitgestellt werden.		Die folgenden Einsatzfälle sind typische Beispiele, an denen sich der praktische Nutzen ablesen lässt. Es ist keine abschliessende Liste - alles, was sich in OBS-Skripten abbilden lässt, kann auch über einen Endpunkt bereitgestellt werden.

			{{Hinweis\|Dies sind Beispiele. Für die konkrete Entwicklung können, je nach Komplexität, weitere Kosten anfallen.}}

	===Webseiten und Kundenportale===		===Webseiten und Kundenportale===

Rademacker am 19. Mai 2026 um 06:27 Uhr

2026-05-19T06:27:02Z

← Nächstältere Version		Version vom 19. Mai 2026, 07:27 Uhr
Zeile 5:		Zeile 5:
	==Was leistet der REST-Server?==		==Was leistet der REST-Server?==

	Der REST-Server ist die '''universelle Schnittstelle''' Ihrer OBS-Installation nach ~~aussen~~. Er macht aus Ihrem OBS einen Dienst, mit dem andere Programme - Webseiten, Apps, ~~Geraete~~, Kundensysteme, Cloud-Dienste - direkt sprechen ~~koennen~~. Statt Daten manuell zu exportieren, zu mailen oder ~~ueber~~ Umwege bereitzustellen, holen sich angebundene Systeme genau die Information, die sie brauchen, in dem Moment, in dem sie sie brauchen - oder liefern neue Daten direkt in OBS ab.		Der REST-Server ist die '''universelle Schnittstelle''' Ihrer OBS-Installation nach außen. Er macht aus Ihrem OBS einen Dienst, mit dem andere Programme - Webseiten, Apps, Geräte, Kundensysteme, Cloud-Dienste - direkt sprechen können. Statt Daten manuell zu exportieren, zu mailen oder über Umwege bereitzustellen, holen sich angebundene Systeme genau die Information, die sie brauchen, in dem Moment, in dem sie sie brauchen - oder liefern neue Daten direkt in OBS ab.

	~~Fuer~~ Anwender, die nicht selbst programmieren, bedeutet das: '''Was bisher nur manuell, per Datei-Import oder ~~ueber~~ Spezialschnittstellen ging, ~~laesst~~ sich jetzt automatisieren.''' Eine Webseite zeigt live aktuelle ~~Lagerbestaende~~. Mitarbeiter erfassen Zeiten ~~ueber~~ das Handy, ohne dass jemand Excel-Listen einpflegen muss. Ein Kunde ~~stoesst~~ per Bestelltaste in seinem System einen Vorgang in Ihrem OBS an. Ein Lieferant meldet ~~Wareneingaenge~~ automatisch ~~zurueck~~. Jeder dieser ~~Anwendungsfaelle~~ wird einmal eingerichtet und ~~laeuft~~ danach automatisch.		Für Anwender, die nicht selbst programmieren, bedeutet das: '''Was bisher nur manuell, per Datei-Import oder über Spezialschnittstellen ging, lässt sich jetzt automatisieren.''' Eine Webseite zeigt live aktuelle Lagerbestände. Mitarbeiter erfassen Zeiten über das Handy, ohne dass jemand Excel-Listen einpflegen muss. Ein Kunde stößt per Bestelltaste in seinem System einen Vorgang in Ihrem OBS an. Ein Lieferant meldet Wareneingänge automatisch zurück. Jeder dieser Anwendungsfälle wird einmal eingerichtet und läuft danach automatisch.

	Technisch gesehen ist der REST-Server ein in OBS integrierter, voll konfigurierbarer '''HTTP/HTTPS-Dienst''', dessen Endpunkte ~~ueber~~ in OBS gepflegte Pascal-Skripte realisiert werden. Jeder Endpunkt bekommt eine eigene Adresse, eine eigene Logik und eine eigene Berechtigungsstruktur. ~~Rueckgaben~~ erfolgen ausschliesslich im JSON-Format. Damit lassen sich beliebige Lese- und ~~Schreibvorgaenge~~ auf der OBS-Datenbank realisieren, ohne dass externe Systeme direkten Datenbank-Zugriff erhalten - das ganze OBS-Regelwerk (Rechte, Validierung, ~~Geschaeftslogik~~) bleibt aktiv.		Technisch gesehen ist der REST-Server ein in OBS integrierter, voll konfigurierbarer '''HTTP/HTTPS-Dienst''', dessen Endpunkte über in OBS gepflegte Pascal-Skripte realisiert werden. Jeder Endpunkt bekommt eine eigene Adresse, eine eigene Logik und eine eigene Berechtigungsstruktur. Rückgaben erfolgen ausschliesslich im JSON-Format. Damit lassen sich beliebige Lese- und Schreibvorgänge auf der OBS-Datenbank realisieren, ohne dass externe Systeme direkten Datenbank-Zugriff erhalten - das ganze OBS-Regelwerk (Rechte, Validierung, Geschäftslogik) bleibt aktiv.

	Im Ergebnis ist der REST-Server kein einzelnes Feature, sondern ein '''Werkzeugkasten''': Was an Daten oder Funktionen in OBS ~~verfuegbar~~ ist, kann ~~ueber~~ den REST-Server auch nach ~~aussen~~ angeboten - oder von ~~aussen~~ entgegengenommen - werden. Die Bandbreite reicht vom einfachen Lese-Endpunkt ~~fuer~~ ein Webseiten-Widget bis hin zu kompletten B2B-Integrationen mit Mandanten- und Rollen-Trennung.		Im Ergebnis ist der REST-Server kein einzelnes Feature, sondern ein '''Werkzeugkasten''': Was an Daten oder Funktionen in OBS verfügbar ist, kann über den REST-Server auch nach außen angeboten - oder von außen entgegengenommen - werden. Die Bandbreite reicht vom einfachen Lese-Endpunkt für ein Webseiten-Widget bis hin zu kompletten B2B-Integrationen mit Mandanten- und Rollen-Trennung.

	Aufruf des Moduls in OBS:		Aufruf des Moduls in OBS:
Zeile 18:		Zeile 18:
	==Anwendungsbereiche==		==Anwendungsbereiche==

	Die folgenden ~~Einsatzfaelle~~ sind typische Beispiele, an denen sich der praktische Nutzen ablesen ~~laesst~~. Es ist keine abschliessende Liste - alles, was sich in OBS-Skripten abbilden ~~laesst~~, kann auch ~~ueber~~ einen Endpunkt bereitgestellt werden.		Die folgenden Einsatzfälle sind typische Beispiele, an denen sich der praktische Nutzen ablesen lässt. Es ist keine abschliessende Liste - alles, was sich in OBS-Skripten abbilden lässt, kann auch über einen Endpunkt bereitgestellt werden.

	===Webseiten und Kundenportale===		===Webseiten und Kundenportale===

	* '''Live-Daten auf der eigenen Webseite:''' ~~Lagerbestaende~~, ~~Verfuegbarkeiten~~, Preise, Auftragsstatus aus OBS direkt anzeigen, ohne ~~taegliche~~ Datei-Exports.		* '''Live-Daten auf der eigenen Webseite:''' Lagerbestände, Verfügbarkeiten, Preise, Auftragsstatus aus OBS direkt anzeigen, ohne tägliche Datei-Exports.
	* '''Kundenportale:''' Kunden sehen ihre offenen Posten, Auftragshistorie, Lieferscheine. Die Seite holt sich die Daten zur Anzeigezeit direkt aus OBS, jeder Kunde sieht nur seine eigenen Daten.		* '''Kundenportale:''' Kunden sehen ihre offenen Posten, Auftragshistorie, Lieferscheine. Die Seite holt sich die Daten zur Anzeigezeit direkt aus OBS, jeder Kunde sieht nur seine eigenen Daten.
	* '''Trackingseiten:''' Status einer Bestellung, eines Auftrags oder einer Reparatur ~~fuer~~ Endkunden, abrufbar ~~ueber~~ eine Sendungsnummer.		* '''Trackingseiten:''' Status einer Bestellung, eines Auftrags oder einer Reparatur für Endkunden, abrufbar über eine Sendungsnummer.

	===Mobile Anwendungen und ~~Aussendienst~~===		===Mobile Anwendungen und Außendienst===

	* '''Mobile Zeiterfassung:''' Mitarbeiter buchen Anfang, Pause und Ende ~~ueber~~ Smartphone oder Tablet, die Daten landen direkt in OBS - ohne Zettelwirtschaft.		* '''Mobile Zeiterfassung:''' Mitarbeiter buchen Anfang, Pause und Ende über Smartphone oder Tablet, die Daten landen direkt in OBS - ohne Zettelwirtschaft.
	* '''QR-/Barcode-Scanner und ~~Lagergeraete~~:''' Wareneingang, Inventur, Kommissionierung direkt in OBS abbilden, ohne zwischengeschaltete Software.		* '''QR-/Barcode-Scanner und Lagergeräte:''' Wareneingang, Inventur, Kommissionierung direkt in OBS abbilden, ohne zwischengeschaltete Software.
	* '''~~Aussendienst~~-Apps:''' Techniker sehen ihre ~~Auftraege~~, dokumentieren ~~Einsaetze~~, erfassen Material - synchronisiert mit OBS.		* '''Außendienst-Apps:''' Techniker sehen ihre Aufträge, dokumentieren Einsätze, erfassen Material - synchronisiert mit OBS.

	===Anbindung von Drittsystemen===		===Anbindung von Drittsystemen===

	* '''Webshops:''' Bestellungen werden direkt vom Shop in OBS gemeldet, ~~Lagerbestaende~~ und Preise vom Shop bei OBS abgefragt.		* '''Webshops:''' Bestellungen werden direkt vom Shop in OBS gemeldet, Lagerbestände und Preise vom Shop bei OBS abgefragt.
	* '''Buchhaltungs- und ERP-Systeme:''' Bidirektionaler Austausch von Belegen, Stammdaten und Buchungen.		* '''Buchhaltungs- und ERP-Systeme:''' Bidirektionaler Austausch von Belegen, Stammdaten und Buchungen.
	* '''CRM- und Marketing-Tools:''' Personendaten, ~~Aktivitaeten~~ oder Mailing-~~Empfaenger~~ werden synchron gehalten.		* '''CRM- und Marketing-Tools:''' Personendaten, Aktivitäten oder Mailing-Empfänger werden synchron gehalten.
	* '''Logistikdienstleister:''' ~~Versandauftraege~~ werden ~~uebergeben~~, Tracking-Informationen ~~zurueckgeliefert~~.		* '''Logistikdienstleister:''' Versandaufträge werden übergeben, Tracking-Informationen zurückgeliefert.

	===Automatisierte ~~Rueckmeldungen~~ (WebHooks)===		===Automatisierte Rückmeldungen (WebHooks)===

	* '''Zahlungs-Callbacks:''' Bezahldienste (z.B. PayPal, Klarna, Stripe) melden den Zahlungseingang an einen WebHook-Endpunkt - OBS bucht automatisch.		* '''Zahlungs-Callbacks:''' Bezahldienste (z.B. PayPal, Klarna, Stripe) melden den Zahlungseingang an einen WebHook-Endpunkt - OBS bucht automatisch.
	* '''Versanddienste:''' Statusmeldungen (verschickt, zugestellt, retour) werden direkt im passenden Vorgang dokumentiert.		* '''Versanddienste:''' Statusmeldungen (verschickt, zugestellt, retour) werden direkt im passenden Vorgang dokumentiert.
	* '''Cloud-Workflows:''' Externe Automatisierungs-Plattformen (Make, Zapier, n8n, ...) ~~stossen~~ OBS-~~Vorgaenge~~ an oder werden von OBS aus angesprochen.		* '''Cloud-Workflows:''' Externe Automatisierungs-Plattformen (Make, Zapier, n8n, ...) stoßen OBS-Vorgänge an oder werden von OBS aus angesprochen.

	===~~Geschaeftspartner~~-Kommunikation (B2B)===		===Geschäftspartner-Kommunikation (B2B)===

	* '''Lieferanten-Schnittstelle:''' Bestellungen werden automatisch ~~uebergeben~~, ~~Auftragsbestaetigungen~~ und Lieferavise ~~zurueckgespielt~~.		* '''Lieferanten-Schnittstelle:''' Bestellungen werden automatisch übergeben, Auftragsbestätigungen und Lieferavise zurückgespielt.
	* '''Kunden-Schnittstelle:''' Grosskunden bestellen direkt aus ihrem ERP heraus, Stammdaten und Konditionen werden zentral gepflegt.		* '''Kunden-Schnittstelle:''' Grosskunden bestellen direkt aus ihrem ERP heraus, Stammdaten und Konditionen werden zentral gepflegt.
	* '''Sichere Maschine-zu-Maschine-Kommunikation:''' Mit Mutual-TLS (mTLS) wird sichergestellt, dass nur die freigeschalteten Partnersysteme - und niemand sonst - mit OBS sprechen ~~koennen~~.		* '''Sichere Maschine-zu-Maschine-Kommunikation:''' Mit Mutual-TLS (mTLS) wird sichergestellt, dass nur die freigeschalteten Partnersysteme - und niemand sonst - mit OBS sprechen können.

	===Interne Microservices und Automatisierungen===		===Interne Microservices und Automatisierungen===

	* '''Eigene kleine Hilfs-Tools:''' Zeitschaltautomatik, Reporting-Generator, Sammelaktionen, die aus mehreren Quellen Daten in OBS verarbeiten.		* '''Eigene kleine Hilfs-Tools:''' Zeitschaltautomatik, Reporting-Generator, Sammelaktionen, die aus mehreren Quellen Daten in OBS verarbeiten.
	* '''Verbindung mehrerer Standorte:''' Verteilte Systeme tauschen Daten ~~ueber~~ definierte Endpunkte aus, ohne offene Datenbankverbindungen.		* '''Verbindung mehrerer Standorte:''' Verteilte Systeme tauschen Daten über definierte Endpunkte aus, ohne offene Datenbankverbindungen.
	* '''Datenbereitstellung ~~fuer~~ Dashboards und Auswertungen:''' BI-Tools (Power BI, Grafana, ...) lesen aufbereitete Kennzahlen direkt aus OBS.		* '''Datenbereitstellung für Dashboards und Auswertungen:''' BI-Tools (Power BI, Grafana, ...) lesen aufbereitete Kennzahlen direkt aus OBS.

	===Was bedeutet das wirtschaftlich?===		===Was bedeutet das wirtschaftlich?===

	* '''Manuelle Arbeit ~~faellt~~ weg.''' Daten werden nicht mehr aus OBS exportiert, per Mail geschickt und woanders eingelesen - sie fliessen direkt.		* '''Manuelle Arbeit fällt weg.''' Daten werden nicht mehr aus OBS exportiert, per Mail geschickt und woanders eingelesen - sie fliessen direkt.
	* '''Fehler werden weniger.''' Jede manuelle Stelle ist eine ~~moegliche~~ Fehlerquelle; jede Automatisierung eine Stelle, an der nichts mehr schiefgehen kann.		* '''Fehler werden weniger.''' Jede manuelle Stelle ist eine mögliche Fehlerquelle; jede Automatisierung eine Stelle, an der nichts mehr schiefgehen kann.
	* '''Neue ~~Geschaeftsmodelle~~ werden ~~moeglich~~.''' Kunden- und Lieferantenportale, Self-Service-Funktionen, App-Anbindungen lassen sich aufbauen, ohne ein zweites System pflegen zu ~~muessen~~.		* '''Neue Geschäftsmodelle werden möglich.''' Kunden- und Lieferantenportale, Self-Service-Funktionen, App-Anbindungen lassen sich aufbauen, ohne ein zweites System pflegen zu müssen.
	* '''Bestehende Software bleibt verbunden.''' Statt eine vorhandene Anwendung ~~abloesen~~ zu ~~muessen~~, kann sie ~~ueber~~ den REST-Server an OBS angedockt werden - in beiden Richtungen.		* '''Bestehende Software bleibt verbunden.''' Statt eine vorhandene Anwendung ablösen zu müssen, kann sie über den REST-Server an OBS angedockt werden - in beiden Richtungen.
	* '''Skaliert mit:''' Was klein ~~anfaengt~~ (ein einzelner Endpunkt ~~fuer~~ eine Webseite) kann zu einer kompletten Integrations-Plattform ausgebaut werden, ohne dass die Grundlage gewechselt werden muss.		* '''Skaliert mit:''' Was klein anfängt (ein einzelner Endpunkt für eine Webseite) kann zu einer kompletten Integrations-Plattform ausgebaut werden, ohne dass die Grundlage gewechselt werden muss.

	==Architektur im Überblick==		==Architektur im Überblick==