Welche Endpunkte gibt es?

Kurzantwort: Jedes Modell bekommt unter /api/rest/<apiPath> einen festen Satz Endpunkte: create, read/{id}, update/{id} (PUT und PATCH), delete/{id}, query, dazu optional {id}/file, {id}/history und {id}/rollback/{revision}. Welche davon existieren, steuert @ExposeApi je Modell. Komplexe Lesevorgänge laufen bewusst über POST, weil der Response Request im Body steht.

---

Der Standardsatz eines Datenmodells

Basis-Pfad: api/rest{apiPath} – der apiPath kommt aus dem Modell (@DataObject(apiPath = ...)).

Methode	Pfad	Zweck	Body	Bedingung
POST	/create	Anlegen (JSON)	WritePayload<{Model}CreatePayload>	create
POST	/create/upload	Anlegen mit Dateien	Multipart: data + files	create und Datei-Modell
POST	/read/{id}	Lesen mit Response Request	ReadPayload	read
GET	/read/{id}	Lesen mit ["*"] als Response	–	read
PUT	/update/{id}	Ersetzen	WritePayload<{Model}UpdatePayload>	update
PUT	/update/{id}/upload	Ersetzen mit Dateien	Multipart	update und Datei-Modell
PATCH	/update/{id}	Teiländerung	PatchPayload	patch
PATCH	/update/{id}/upload	Teiländerung mit Dateien	Multipart	patch und Datei-Modell
DELETE	/delete/{id}	Löschen	–	delete
POST	/query	Suchen/Listen	RestListPayload	query
GET	/{id}/file	Datei herunterladen	–	download
POST	/{id}/history	Revisionsliste	RestListPayload	history
POST	/{id}/rollback/{revision}	auf Revision zurücksetzen	ReadPayload	rollback

Beispiel

Für ein Modell mit apiPath = /crm/customer:

POST   /api/rest/crm/customer/create
POST   /api/rest/crm/customer/read/{id}
GET    /api/rest/crm/customer/read/{id}
PUT    /api/rest/crm/customer/update/{id}
PATCH  /api/rest/crm/customer/update/{id}
DELETE /api/rest/crm/customer/delete/{id}
POST   /api/rest/crm/customer/query

Singleton-Modelle

Ein @Singleton-Modell hat keine ID in der URL – es gibt nur ein Objekt pro Scope:

Methode	Pfad	Zweck
POST	/create	anlegen (schlägt fehl, wenn es schon existiert)
POST	/create/upload	anlegen mit Dateien
POST	/read	lesen mit Response Request
GET	/read	lesen mit ["*"]
PUT	/update	ersetzen
PUT	/update/upload	ersetzen mit Dateien
PATCH	/update	Teiländerung
DELETE	/delete	löschen
GET	/file	Datei herunterladen
POST	/history	Revisionsliste

Abstrakte Modelle – die Hub-API

Ein abstraktes Modell bekommt einen Router-Controller mit denselben Pfaden. Der konkrete Untertyp kommt aus dem Payload:

Methode	Pfad	Woher der Typ kommt
POST	/create, /create/upload	data.@type des Payloads
POST/GET	/read/{id}	aus der Datenbank ermittelt (_MODELTYPE)
PUT	/update/{id}	data.@type
PATCH	/update/{id}	data["@type"]
DELETE	/delete/{id}	aus der Datenbank ermittelt
POST	/query	pro Treffer aus der Datenbank; die Zeilen werden parallel über die Untertyp-APIs geladen

Details in Vererbung und abstrakte Modelle.

Weitere Endpunkte

Pfad	Modul	Zweck
GET /cias/fetch	cdms-authorization	Benutzerprofil des aktuellen Requests (Rollen, Attribute)
POST/GET /api/mcp	CDMS-Hub	MCP-Server, siehe MCP
GET /.well-known/oauth-protected-resource/api/mcp	CDMS-Hub	OAuth-Discovery für MCP-Clients (ohne Token erreichbar)
GET :8081/actuator/health/liveness	alle	Liveness

Warum POST zum Lesen?

GET /read/{id} gibt es, liefert aber immer ["*"] – also alle skalaren Felder plus Referenzen mit ID. Sobald man steuern will, welche Felder und Beziehungen mitkommen, braucht es einen Body; deshalb POST /read/{id} mit ReadPayload. Dasselbe gilt für /query: Filter, Sortierung, Pagination und Response Request sind strukturierte Daten und gehören nicht in eine URL.

Welche Endpunkte ein Modell wirklich hat

Gesteuert über @ExposeApi:

@ExposeApi(create = true, read = true, update = true, patch = true,
           delete = true, query = true,
           download = false, history = false, rollback = false)

Standardmäßig sind create, read, update, patch, delete und query an; download, history und rollback aus. Im Modell steuert die Endpunkt-Konfiguration diese Flags:

Endpoint im Modell	schaltet frei
CreateEndpoint	create
UpdateEndpoint	update und patch
ReadEndpoint	read und query
DeleteEndpoint	delete
SearchEndpoint	search

Rechte je Endpunkt

Jeder Endpunkt prüft eine eigene Rolle aus @AccessByRole: onCreate, onRead, onUpdate, onDelete, onDownload, onHistory, onRollback. Details in Rollen und Rechte.

Bemerkenswert: History liest nur und prüft deshalb die History-Rolle; Rollback schreibt und verlangt zusätzlich die Rollback-Rolle.