OBS/Kostenpflichtige Module/RESTServer/Scripting - Versionsgeschichte

Rademacker am 1. September 2026 um 09:10 Uhr

2026-09-01T09:10:11Z

Rademacker am 31. August 2026 um 05:03 Uhr

2026-08-31T05:03:18Z

← Nächstältere Version		Version vom 31. August 2026, 06:03 Uhr
Zeile 23:		Zeile 23:
	function Patch (oParams: TStrings; oBody: TJSONObject): string;		function Patch (oParams: TStrings; oBody: TJSONObject): string;

	~~Nicht implementierte Methoden liefern automatisch~~ ''405''-~~ähnliche Fehler über~~ die ~~generische~~ Skript-Antwort.		Fehlt die zur Methode passende Funktion, antwortet der Server mit '''405 Method
			Not Allowed''' (<code>METHOD_NOT_ALLOWED</code>) und nennt im Header
			<code>Allow</code> die Verben, die dieses Skript tatsächlich anbietet - die Liste
			stammt aus dem kompilierten Skript und kann deshalb nicht veralten:

			HTTP/1.1 405 Method Not Allowed
			Allow: GET, PUT

			Ein im Vertrag zugesagtes Verb braucht also seine Funktion. Fehlt sie, ist das an
			der Antwort sofort zu erkennen und '''kein''' Serverfehler.

	==Parameter==		==Parameter==
Zeile 189:		Zeile 198:
	\|-		\|-
	\| _OBS_UPLOAD_CONTENTTYPE \|\| Content-Type der Datei (Default <code>application/octet-stream</code>, wenn der Client keinen angibt)		\| _OBS_UPLOAD_CONTENTTYPE \|\| Content-Type der Datei (Default <code>application/octet-stream</code>, wenn der Client keinen angibt)
			\|-
			\| _OBS_UPLOAD_SHA256 \|\| SHA-256 der '''gespeicherten''' Datei, hex in Kleinbuchstaben. Damit lässt sich eine vom Client mitgesendete Prüfsumme vergleichen - erst dieser Vergleich macht aus ihr eine Zusicherung
	\|}		\|}

Zeile 202:		Zeile 213:
	Eine Datei pro Request. Name und Content-Type stammen aus der		Eine Datei pro Request. Name und Content-Type stammen aus der
	<code>Content-Disposition</code> der Datei-Partie (<code>filename=</code>). Der		<code>Content-Disposition</code> der Datei-Partie (<code>filename=</code>). Der
	Server speichert die erste Datei-Partie und ruft das Skript auf:		Server speichert die erste Datei-Partie und ruft das Skript auf.

			Die '''übrigen Partien''' des Formulars - alles ohne <code>filename=</code> -
			übergibt der Server als <code>_OBS_FORM_<name></code>. Der Wert ist UTF-8 und
			auf 1024 Zeichen begrenzt, der Name auf Buchstaben, Ziffern und Unterstrich
			reduziert. Zusatzangaben lassen sich damit im selben Request mitschicken, ohne sie
			an die URL zu hängen:

	<syntaxhighlight lang="pascal" line>		<syntaxhighlight lang="pascal" line>

Rademacker am 19. August 2026 um 12:00 Uhr

2026-08-19T12:00:25Z

← Nächstältere Version		Version vom 19. August 2026, 13:00 Uhr
Zeile 559:		Zeile 559:
	====Refresh-Methode====		====Refresh-Methode====

	Der Refresh läuft über '''denselben JWT-Endpunkt''' und '''dasselbe Skript'''. Liegt am JWT-Endpunkt ein ''Authorization: Bearer <token>'' vor, ruft der Server statt ''Authenticate'' die Methode '''Refresh''' auf (~~sonst~~ Login).		Der Refresh läuft über '''denselben JWT-Endpunkt''' und '''dasselbe Skript'''. Liegt am JWT-Endpunkt ein ''Authorization: Bearer <token>'' mit einem Refresh-Token vor, ruft der Server statt ''Authenticate'' die Methode '''Refresh''' auf (ohne Bearer: Login; ''DELETE'' mit Access-Token: Abmelden, ohne Skript).

	Bevor das Skript läuft, hat der Server das vorgelegte Refresh-Token verifiziert		Bevor das Skript läuft, hat der Server das vorgelegte Refresh-Token verifiziert
Zeile 602:		Zeile 602:
	// Rolle und Mandant neu lesen, nicht aus dem alten Token uebernehmen -		// Rolle und Mandant neu lesen, nicht aus dem alten Token uebernehmen -
	// sonst wirkt ein Rechteentzug erst beim naechsten Login.		// sonst wirkt ein Rechteentzug erst beim naechsten Login.

	oRes.AddPair('status' , 1);		oRes.AddPair('status' , 1);
	oRes.AddPair('_OBS_JWT_ID' , cUser);		oRes.AddPair('_OBS_JWT_ID' , cUser);
Zeile 618:		Zeile 617:
	===Abmelden (Logout)===		===Abmelden (Logout)===

	~~Das~~ Abmelden ~~ist~~ ein ~~gewöhnlicher~~ Endpunkt - '''~~nicht~~''' ~~Teil des~~		'''Für das Abmelden braucht das Skript keine Methode.''' Es läuft über ein
	~~Authentifizierungs~~-~~Skripts. Er wird mit dem Access~~-Token ~~aufgerufen~~ und setzt		''DELETE'' auf denselben JWT-Endpunkt (Access-Token im ''Authorization''-Header)
	''_OBS_JWT_REVOKE'':		und wird komplett in der Engine erledigt: die Sitzung wird gesperrt, die Antwort
			ist 204. Eine Methode ''Logout'' gibt es nicht und wird nicht aufgerufen.
			Details: [[OBS/Kostenpflichtige Module/RESTServer/Zugaenge\|Zugänge]], Phase 4.

			Wer beim Abmelden zusätzlich fachlich etwas tun will - eine Geräteregistrierung
			löschen, einen Push-Token verwerfen, den Vorgang protokollieren - nimmt einen
			'''gewöhnlichen Endpunkt''' und setzt dort ''_OBS_JWT_REVOKE''. Dasselbe gilt für
			"auf allen Geräten abmelden", weil das eine Berechtigungsentscheidung braucht:

	<syntaxhighlight lang="pascal" line>		<syntaxhighlight lang="pascal" line>
Zeile 628:		Zeile 634:
	oRes := TJSONObject.Create();		oRes := TJSONObject.Create();
	try		try
			GeraeteRegistrierungLoeschen(oParams.Values['_OBS_JWT_SUBJECT']);

	// 'session' = diese Sitzung, 'all' = alle Sitzungen des Subjects		// 'session' = diese Sitzung, 'all' = alle Sitzungen des Subjects
	oRes.AddPair('_OBS_JWT_REVOKE' , 'session');		oRes.AddPair('_OBS_JWT_REVOKE' , 'session');
Zeile 638:		Zeile 646:
	</syntaxhighlight>		</syntaxhighlight>

	Gesperrt wird die '''ganze Sitzung''', also auch die noch nicht abgelaufenen		Gesperrt wird in beiden Wegen die '''ganze Sitzung''', also auch die noch nicht
	Access-Token vorheriger Erneuerungen. Ein wiederholter Aufruf ist unschädlich.		abgelaufenen Access-Token vorheriger Erneuerungen. Ein wiederholter Aufruf ist
	Lässt sich die Sitzung nicht sperren, überschreibt der Server die Antwort des		unschädlich. Lässt sich die Sitzung nicht sperren, überschreibt der Server die
	Skripts mit '''503''' - ein Client darf nicht glauben, er sei abgemeldet, während		Antwort des Skripts mit '''503''' - ein Client darf nicht glauben, er sei
	sein Token weiterläuft.		abgemeldet, während sein Token weiterläuft.

	==Fehlerbehandlung im Skript==		==Fehlerbehandlung im Skript==

Rademacker am 19. August 2026 um 10:14 Uhr

2026-08-19T10:14:28Z

Änderungen zeigen

Rademacker am 17. August 2026 um 08:15 Uhr

2026-08-17T08:15:19Z

Änderungen zeigen

Rademacker am 17. August 2026 um 06:51 Uhr

2026-08-17T06:51:19Z

Änderungen zeigen

Rademacker am 30. Juni 2026 um 11:28 Uhr

2026-06-30T11:28:44Z

← Nächstältere Version		Version vom 30. Juni 2026, 12:28 Uhr
Zeile 102:		Zeile 102:
	[[OBS/Kostenpflichtige Module/RESTServer/Endpunkte\|Endpunkte]]), nimmt der Server		[[OBS/Kostenpflichtige Module/RESTServer/Endpunkte\|Endpunkte]]), nimmt der Server
	hochgeladene Dateien entgegen, legt sie in einem temporären Verzeichnis ab und		hochgeladene Dateien entgegen, legt sie in einem temporären Verzeichnis ab und
	übergibt dem Skript ~~den~~ Pfad über reservierte Parameter. Das Skript entscheidet		übergibt dem Skript Pfad, Originalname und Content-Type über reservierte
	selbst über die weitere Verarbeitung (z.B. DMS-Ablage). Der Body wird in diesem		Parameter. Das Skript entscheidet selbst über die weitere Verarbeitung (z.B.
	Fall '''nicht''' als JSON geparst - ''oBody'' ist ''nil''. Es gilt nicht das		DMS-Ablage). Der Body wird in diesem Fall '''nicht''' als JSON geparst - ''oBody''
	JSON-Body-Limit (10 MB), sondern die pro Endpunkt konfigurierte Grösse		ist ''nil''. Es gilt nicht das JSON-Body-Limit (10 MB), sondern die pro
	(''re_upload_size'', Standard 25 MB; Überschreitung -> 413).		Endpunkt konfigurierte Grösse (''re_upload_size'', Standard 25 MB;
			Überschreitung -> 413).

			Beide Übertragungsarten - <code>multipart/form-data</code> und der resumable
			<code>Content-Range</code>-Upload - liefern dem Skript dieselben Parameter:

	{\| class="wikitable"		{\| class="wikitable"
Zeile 113:		Zeile 117:
	\| _OBS_UPLOAD_PATH \|\| Vollständiger Pfad zur temporären Datei auf dem Server		\| _OBS_UPLOAD_PATH \|\| Vollständiger Pfad zur temporären Datei auf dem Server
	\|-		\|-
	\| _OBS_UPLOAD_NAME \|\| ~~Ursprünglicher Dateiname (nur bei multipart/form-data)~~		\| _OBS_UPLOAD_NAME \|\| Originaldateiname
	\|-		\|-
	\| _OBS_UPLOAD_CONTENTTYPE \|\| Content-Type der Datei ~~laut Client~~ (~~nur bei multipart~~/~~form~~-~~data~~)		\| _OBS_UPLOAD_CONTENTTYPE \|\| Content-Type der Datei (Default <code>application/octet-stream</code>, wenn der Client keinen angibt)
	\|}		\|}

			Der '''Dateiname ist Pflicht'''. Fehlt er, lehnt der Server den Upload mit
			'''400 Bad Request''' ab und das Skript wird nicht ausgeführt - das Skript kann
			sich also darauf verlassen, dass ''_OBS_UPLOAD_PATH'' und ''_OBS_UPLOAD_NAME''
			gesetzt sind, sobald es läuft.

	{{Hinweis\|Die temporäre Datei wird nicht automatisch verschoben. Das Skript muss sie an ihren Zielort (DMS, Verzeichnis, ...) übernehmen.}}		{{Hinweis\|Die temporäre Datei wird nicht automatisch verschoben. Das Skript muss sie an ihren Zielort (DMS, Verzeichnis, ...) übernehmen.}}
Zeile 122:		Zeile 131:
	====Einfacher Upload (multipart/form-data)====		====Einfacher Upload (multipart/form-data)====

	Eine Datei pro Request. Der Server speichert die erste Datei-Partie und ruft das		Eine Datei pro Request. Name und Content-Type stammen aus der
	Skript ~~mit den drei Parametern~~ auf:		<code>Content-Disposition</code> der Datei-Partie (<code>filename=</code>). Der
			Server speichert die erste Datei-Partie und ruft das Skript auf:

	<syntaxhighlight lang="pascal" line>		<syntaxhighlight lang="pascal" line>
Zeile 130:		Zeile 140:
	cPfad: string;		cPfad: string;
	cName: string;		cName: string;
			cTyp : string;
	begin		begin
	oRes := TJSONObject.Create();		oRes := TJSONObject.Create();
Zeile 135:		Zeile 146:
	cPfad := oParams.Values['_OBS_UPLOAD_PATH'];		cPfad := oParams.Values['_OBS_UPLOAD_PATH'];
	cName := oParams.Values['_OBS_UPLOAD_NAME'];		cName := oParams.Values['_OBS_UPLOAD_NAME'];
			cTyp := oParams.Values['_OBS_UPLOAD_CONTENTTYPE'];
	~~if (Empty(cPfad)) then begin~~
	~~oRes.AddPair('_OBS_HTTP_STATUS', 400);~~
	~~oRes~~.~~AddPair(~~'~~error~~'~~, 'Keine Datei empfangen');~~
	~~result := oRes.ToJSON();~~
	~~exit;~~
	~~end~~;

	// ... Datei aus cPfad ins DMS / Zielverzeichnis uebernehmen ...		// ... Datei aus cPfad ins DMS / Zielverzeichnis uebernehmen ...
Zeile 160:		Zeile 165:
	Chunks '''sequentiell''' an eine Session-Datei an und behandelt unvollständige		Chunks '''sequentiell''' an eine Session-Datei an und behandelt unvollständige
	Uploads selbst - das Endpunkt-Skript läuft '''erst beim vollständigen Upload'''		Uploads selbst - das Endpunkt-Skript läuft '''erst beim vollständigen Upload'''
	(dann mit gesetztem ''_OBS_UPLOAD_PATH''; ''_OBS_UPLOAD_NAME'' und		(dann mit gesetztem ''_OBS_UPLOAD_PATH'', ''_OBS_UPLOAD_NAME'' und
	''_OBS_UPLOAD_CONTENTTYPE'' sind ~~hier~~ nicht ~~gesetzt~~).		''_OBS_UPLOAD_CONTENTTYPE'').

			Name und Content-Type sind im <code>Content-Range</code>-Protokoll nicht enthalten;
			der Client liefert sie deshalb '''im ersten Chunk''' über den Header
			<code>Upload-Metadata</code> (Format wie bei tus: kommagetrennte Paare
			<code>schlüssel base64wert</code>, Werte Base64-kodiert):

			<pre>
			Upload-Metadata: filename ZmlsZS5wZGY=,filetype YXBwbGljYXRpb24vcGRm
			</pre>

			Erkannt werden die Schlüssel <code>filename</code> (Pflicht) und
			<code>filetype</code> (optional). Fehlt <code>filename</code> im ersten Chunk,
			wird der Upload mit '''400''' abgelehnt, ohne dass eine Datei angelegt wird.
			Folge-Chunks und Statusabfragen müssen die Metadaten nicht erneut senden.

	Ablauf (vom Client gesteuert, der Server antwortet jeweils):		Ablauf (vom Client gesteuert, der Server antwortet jeweils):
Zeile 168:		Zeile 187:
	! Request !! Server-Antwort		! Request !! Server-Antwort
	\|-		\|-
	\| Chunk <code>Content-Range: bytes 0-1048575/5000000</code> \|\| '''308''' Resume Incomplete + Header <code>Upload-Id</code>, <code>Upload-Offset</code>, <code>Range</code>		\| Erster Chunk <code>Content-Range: bytes 0-1048575/5000000</code> + <code>Upload-Metadata</code> \|\| '''308''' Resume Incomplete + Header <code>Upload-Id</code>, <code>Upload-Offset</code>, <code>Range</code>
	\|-		\|-
	\| weitere Chunks (jeweils <code>Upload-Id</code> mitsenden) \|\| '''308''' mit aktualisiertem <code>Upload-Offset</code>		\| weitere Chunks (jeweils <code>Upload-Id</code> mitsenden) \|\| '''308''' mit aktualisiertem <code>Upload-Offset</code>
Zeile 181:		Zeile 200:
	\|-		\|-
	\| Content-Range \|\| Request \|\| <code>bytes START-END/TOTAL</code>; <code>bytes */TOTAL</code> nur als Statusabfrage		\| Content-Range \|\| Request \|\| <code>bytes START-END/TOTAL</code>; <code>bytes */TOTAL</code> nur als Statusabfrage
			\|-
			\| Upload-Metadata \|\| Request \|\| tus-Metadaten im ersten Chunk: <code>filename</code> (Pflicht), <code>filetype</code> (optional), Base64-kodiert
	\|-		\|-
	\| Upload-Id \|\| Request/Response \|\| Session-Kennung. Fehlt sie im ersten Request, erzeugt der Server eine und gibt sie zurück; alle Folge-Chunks müssen sie mitsenden.		\| Upload-Id \|\| Request/Response \|\| Session-Kennung. Fehlt sie im ersten Request, erzeugt der Server eine und gibt sie zurück; alle Folge-Chunks müssen sie mitsenden.
Zeile 193:		Zeile 214:
	sondern der aktuelle ''Upload-Offset'' zurückgemeldet - der Client setzt ab dort		sondern der aktuelle ''Upload-Offset'' zurückgemeldet - der Client setzt ab dort
	neu auf. Eine separate Statusabfrage ist für ein Resume daher nicht zwingend nötig.		neu auf. Eine separate Statusabfrage ist für ein Resume daher nicht zwingend nötig.

			Überschreitet ein Chunk bzw. die Gesamtgrösse das Limit (''re_upload_size''),
			antwortet der Server mit '''413 Payload Too Large'''.

	{{Hinweis\|Der Upload-Status liegt prozesslokal im Speicher. Nach einem Neustart des Servers muss ein unvollständiger Upload neu begonnen werden.}}		{{Hinweis\|Der Upload-Status liegt prozesslokal im Speicher. Nach einem Neustart des Servers muss ein unvollständiger Upload neu begonnen werden.}}

Rademacker am 30. Juni 2026 um 10:53 Uhr

2026-06-30T10:53:03Z

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

	Da der Präfix ''_OBS_'' für von aussen gelieferte Header- und Query-Parameter gesperrt ist, sind diese Werte nicht durch den Client fälschbar. Ein vollständiges Beispiel zeigt [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel 4 - Pfad-Parameter]].		Da der Präfix ''_OBS_'' für von aussen gelieferte Header- und Query-Parameter gesperrt ist, sind diese Werte nicht durch den Client fälschbar. Ein vollständiges Beispiel zeigt [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel 4 - Pfad-Parameter]].

			===Datei-Uploads===

			Ist der Endpunkt für Uploads freigeschaltet (<code>re_upload = 1</code>, siehe
			[[OBS/Kostenpflichtige Module/RESTServer/Endpunkte\|Endpunkte]]), nimmt der Server
			hochgeladene Dateien entgegen, legt sie in einem temporären Verzeichnis ab und
			übergibt dem Skript den Pfad über reservierte Parameter. Das Skript entscheidet
			selbst über die weitere Verarbeitung (z.B. DMS-Ablage). Der Body wird in diesem
			Fall '''nicht''' als JSON geparst - ''oBody'' ist ''nil''. Es gilt nicht das
			JSON-Body-Limit (10 MB), sondern die pro Endpunkt konfigurierte Grösse
			(''re_upload_size'', Standard 25 MB; Überschreitung -> 413).

			{\| class="wikitable"
			! Parameter !! Inhalt
			\|-
			\| _OBS_UPLOAD_PATH \|\| Vollständiger Pfad zur temporären Datei auf dem Server
			\|-
			\| _OBS_UPLOAD_NAME \|\| Ursprünglicher Dateiname (nur bei multipart/form-data)
			\|-
			\| _OBS_UPLOAD_CONTENTTYPE \|\| Content-Type der Datei laut Client (nur bei multipart/form-data)
			\|}

			{{Hinweis\|Die temporäre Datei wird nicht automatisch verschoben. Das Skript muss sie an ihren Zielort (DMS, Verzeichnis, ...) übernehmen.}}

			====Einfacher Upload (multipart/form-data)====

			Eine Datei pro Request. Der Server speichert die erste Datei-Partie und ruft das
			Skript mit den drei Parametern auf:

			<syntaxhighlight lang="pascal" line>
			function Post(oParams: TStrings; oBody: TJSONObject): string;
			var oRes : TJSONObject;
			cPfad: string;
			cName: string;
			begin
			oRes := TJSONObject.Create();
			try
			cPfad := oParams.Values['_OBS_UPLOAD_PATH'];
			cName := oParams.Values['_OBS_UPLOAD_NAME'];

			if (Empty(cPfad)) then begin
			oRes.AddPair('_OBS_HTTP_STATUS', 400);
			oRes.AddPair('error', 'Keine Datei empfangen');
			result := oRes.ToJSON();
			exit;
			end;

			// ... Datei aus cPfad ins DMS / Zielverzeichnis uebernehmen ...

			oRes.AddPair('status' , 'ok');
			oRes.AddPair('dateiname', cName);
			result := oRes.ToJSON();
			finally
			MyFreeAndNil(oRes);
			end;
			end;
			</syntaxhighlight>

			====Resumable/Chunked Upload (Content-Range)====

			Für grosse Dateien überträgt der Client die Datei in Teilstücken (Chunks) mit dem
			Header <code>Content-Range: bytes START-END/TOTAL</code>. Der Server hängt die
			Chunks '''sequentiell''' an eine Session-Datei an und behandelt unvollständige
			Uploads selbst - das Endpunkt-Skript läuft '''erst beim vollständigen Upload'''
			(dann mit gesetztem ''_OBS_UPLOAD_PATH''; ''_OBS_UPLOAD_NAME'' und
			''_OBS_UPLOAD_CONTENTTYPE'' sind hier nicht gesetzt).

			Ablauf (vom Client gesteuert, der Server antwortet jeweils):

			{\| class="wikitable"
			! Request !! Server-Antwort
			\|-
			\| Chunk <code>Content-Range: bytes 0-1048575/5000000</code> \|\| '''308''' Resume Incomplete + Header <code>Upload-Id</code>, <code>Upload-Offset</code>, <code>Range</code>
			\|-
			\| weitere Chunks (jeweils <code>Upload-Id</code> mitsenden) \|\| '''308''' mit aktualisiertem <code>Upload-Offset</code>
			\|-
			\| letzter Chunk (Bereich erreicht TOTAL) \|\| normale Skript-Antwort (z.B. '''200'''/'''201''')
			\|-
			\| Statusabfrage <code>Content-Range: bytes */5000000</code> \|\| aktueller <code>Upload-Offset</code>, ohne anzuhängen (Resume)
			\|}

			{\| class="wikitable"
			! Header !! Richtung !! Bedeutung
			\|-
			\| Content-Range \|\| Request \|\| <code>bytes START-END/TOTAL</code>; <code>bytes */TOTAL</code> nur als Statusabfrage
			\|-
			\| Upload-Id \|\| Request/Response \|\| Session-Kennung. Fehlt sie im ersten Request, erzeugt der Server eine und gibt sie zurück; alle Folge-Chunks müssen sie mitsenden.
			\|-
			\| Upload-Offset \|\| Response \|\| Anzahl der bereits gespeicherten Bytes (= Startoffset des nächsten Chunks)
			\|-
			\| Range \|\| Response \|\| Bereits gespeicherter Bereich (<code>bytes=0-N</code>)
			\|}

			Der Server hängt einen Chunk '''nur an, wenn START dem bereits gespeicherten Stand
			entspricht'''. Bei Abweichung (doppelter Chunk, Lücke) wird nicht angehängt,
			sondern der aktuelle ''Upload-Offset'' zurückgemeldet - der Client setzt ab dort
			neu auf. Eine separate Statusabfrage ist für ein Resume daher nicht zwingend nötig.

			{{Hinweis\|Der Upload-Status liegt prozesslokal im Speicher. Nach einem Neustart des Servers muss ein unvollständiger Upload neu begonnen werden.}}

	==Rückgabe==		==Rückgabe==

Rademacker am 29. Juni 2026 um 10:06 Uhr

2026-06-29T10:06:51Z

Änderungen zeigen

Rademacker am 15. Juni 2026 um 07:24 Uhr

2026-06-15T07:24:18Z

← Nächstältere Version		Version vom 15. Juni 2026, 08:24 Uhr
Zeile 78:		Zeile 78:

	Diese Werte werden vom Server gesetzt und können vom Skript für Berechtigungs- und Mandantenprüfungen verwendet werden.		Diese Werte werden vom Server gesetzt und können vom Skript für Berechtigungs- und Mandantenprüfungen verwendet werden.

			===Pfad-Parameter===

			Stammt der Endpunkt aus einem Pfad-Template mit Platzhaltern (siehe [[OBS/Kostenpflichtige Module/RESTServer/Endpunkte\|Endpunkte]]), stehen die aus den Platzhaltern erfassten Werte als reservierte Parameter mit Präfix '''_OBS_PATH_''' in ''oParams'' bereit:

			{\| class="wikitable"
			! Template !! Zugriff im Skript
			\|-
			\| <code>/orders/{uid}</code> \|\| ''oParams.Values['_OBS_PATH_uid']''
			\|-
			\| <code>/orders/{uid}/modules/{code}</code> \|\| ''oParams.Values['_OBS_PATH_uid']'', ''oParams.Values['_OBS_PATH_code']''
			\|}

			Da der Präfix ''_OBS_'' für von aussen gelieferte Header- und Query-Parameter gesperrt ist, sind diese Werte nicht durch den Client fälschbar. Ein vollständiges Beispiel zeigt [[OBS/Kostenpflichtige Module/RESTServer/Beispiel4\|Beispiel 4 - Pfad-Parameter]].

	==Rückgabe==		==Rückgabe==
Zeile 181:		Zeile 195:
	==Skript-Cache==		==Skript-Cache==

	Der Server cached das kompilierte Skript pro Endpunkt. ~~Änderungen am~~ Skript über F7 ~~sind sofort~~ wirksam - ~~der Server erkennt die Änderung am ''sys_date'' und compiliert neu~~.		Der Server cached das kompilierte Skript pro Endpunkt (Schlüssel: ''sys_date'' des Endpunkts). Zusätzlich werden die Endpunkt-Definitionen pro Server-Profil in einem TTL-Cache (Standard 60 s) gehalten. Eine Skript-Änderung über F7 wird daher erst nach Ablauf dieses TTL (bzw. nach einer Cache-Invalidierung) wirksam - typischerweise innerhalb einer Minute, nicht zwingend sofort.

	==Verfügbare Bibliotheken==		==Verfügbare Bibliotheken==
Zeile 197:		Zeile 211:
	* [[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]]