OBS/Kostenpflichtige Module/RESTServer
- A Preise aktualisieren
- C Personen übertragen
- E Kategorien verwalten
- G Kataloge verwalten
- I Merkliste übertragen
- K Varianten übertragen
- L Artikelvarianten übertragen
- M Referenzarten übertragen
- N Lagerbestände verwalten
- U Bestellungen einlesen
- V leere Passworte füllen
- W Update-Informationen zurücksetzen
- X Konfiguration
- Z Protokoll
REST-Server
Der OBS REST-Server stellt einen frei konfigurierbaren HTTP/HTTPS-Dienst bereit, über den externe Teilnehmer auf Funktionen und Daten der OBS-Datenbank zugreifen können. Jeder Endpunkt wird über ein in OBS gepflegtes Pascal-Script bedient, die Rückgaben erfolgen ausschliesslich im JSON-Format.
Aufruf des Moduls in OBS: Stammdaten -> Z Weitere Stammdaten -> REST-Server
Anwendungsbereiche
Typische Einsatzfälle:
- Bereitstellung von OBS-Daten für Webseiten (Steürungsdaten, Statistiken, Verfügbarkeiten)
- Anbindung mobiler Endgeräte (Zeiterfassung, QR-Scanner, Lagerlisten)
- Integration mit Drittsystemen (ERP, Shop, Buchhaltung) über JSON-APIs
- Empfang von WebHook-Aufrufen externer Dienste (z.B. Bezahl-Callbacks)
- Bereitstellung interner Microservices mit gegenseitiger Authentifizierung (mTLS)
Architektur im Überblick
Der REST-Server besteht aus mehreren aufeinander aufbauenden Bausteinen, die alle in OBS gepflegt werden:
| Baustein | Tabelle | Zweck |
|---|---|---|
| Server | RESTSRV_SERVER | TLS-Profil + eigene HTTP-Server-Instanz, kann mehrfach existieren |
| Bindung | RESTSRV_BINDINGS | IP-Adresse + Port pro Server |
| Zugang | RESTSRV_ACCOUNT | API-Key, optionale Host- und CORS-Beschränkung, optionale JWT-Konfiguration |
| Endpunkt | RESTSRV_ENDPOINTS | Skript, das die Anfrage bearbeitet, einem Server fest zugeordnet |
| Berechtigung | RESTSRV_ACCESS | Verbindet Zugang und Endpunkt |
| Protokoll | RESTSRV_PROTO | Laufende Ereignisse, Fehler, Audit-Einträge |
| Statistik | RESTSRV_STATS | Aufrufzähler, Antwortzeiten und HTTP-Status pro Endpunkt |
Eine Anfrage durchläuft folgende Stationen:
- Rate-Limit-Prüfung (pro IP und global)
- Authentifizierung über den API-Key (Header apikey)
- CORS-Prüfung (sofern Origin-Header gesetzt)
- Optional: JWT-Prüfung (sofern für den Zugang aktiviert)
- Auflösung von Endpunkt / Sub-URL / Version
- Prüfung der Berechtigung (Zugang -> Endpunkt)
- Ausführung des Endpunkt-Skripts (oder WebHook-Antwort)
- JSON-Antwort, Statistik-Eintrag, Protokoll-Eintrag
Adressierung
Ein Endpunkt wird über drei Bestandteile angesprochen: Endpunkt-Name, optionale Sub-URL und Version:
http://[Hostadresse][:Port]/[Endpunkt][/Sub-URL]/[Version]
Beispiele:
https://api.meinserver.de/kalender/v1 https://api.meinserver.de/email/mein_konto/v1.0 https://api.meinserver.de/zeiterfa/mobile/v2
Durch die Versionierung kann eine Endpunkt-Funktionalität verändert werden, ohne bestehende Konsumenten zu brechen.
Unterstützte HTTP-Methoden
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 Scripting.
Sicherheitsmerkmale
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.
- 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.
- 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.
- TLS: Bei Profilen mit aktivem TLS fährt der Server ohne Zertifikat und Key nicht hoch. Plain-HTTP ist nur für ein dediziertes Debug-Profil möglich.
- mTLS (Mutual TLS): erzwingt, dass jeder Client ein gültiges Client-Zertifikat vorlegt. Optional kann pro Zugang ein erwarteter Subject-DN hinterlegt werden.
- DNS-Cache: Host-zu-IP-Auflösungen für die Zugangs-Host-Prüfung werden 5 Minuten gecached.
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.
Statistik
Die Tabelle RESTSRV_STATS enthält eine Statistik aller bearbeiteten Anfragen mit Zugang, Endpunkt, Methode, HTTP-Status und Laufzeit in Millisekunden. Aufruf der Statistik:
- Aus der Endpunkt-Liste: F8 zeigt die Statistik des markierten Endpunkts.
- Aus der Zugänge-Liste: F8 zeigt die Statistik des markierten Zugangs.
Konsole
Wird der REST-Server nicht als Dienst, sondern interaktiv gestartet, erscheint eine farbige Konsole mit Live-Log. Die wichtigsten Befehle:
| Befehl | Wirkung |
|---|---|
| show <n> | Zeigt die Details zum Debug-Eintrag #n (z.B. Request-Header, Response-Body), JSON wird farbig formatiert |
| exit / quit | Beendet den Server geordnet |
Im Service-Modus (Windows-Dienst) ist die Konsole nicht sichtbar. Alle Einträge landen dort ausschliesslich in der Tabelle RESTSRV_PROTO.
Weiterführende Seiten
- Einrichtung - Schritt-für-Schritt-Anleitung
- Server-Profile - TLS, mTLS und Bindungen
- Zugänge - API-Keys, JWT, CORS, Host-Beschränkung
- Endpunkte - Verwaltung, Berechtigungen, WebHooks
- Scripting - Aufbau der Endpunkt-Skripte
- Beispiel: Daten-Abruf mit JWT
- Beispiel: Datensatz anlegen mit JSON-Body