nexarch/dms/docs/CMIS.md

CMIS-Schnittstelle (INT-09, optional)

CMIS 1.1 Browser Binding (JSON) als zusaetzliche Schnittstelle neben der REST-API. Sie hat keine eigene Fachlogik und keine eigenen Rechte: jede CMIS-Anfrage wird in Aufrufe der REST-API uebersetzt, die in-process durch dieselbe Kette laufen wie ein direkter REST-Zugriff (Core-JWT, Rechteentscheidung je Route, Eigentuemer-Regeln, Mandantenpruefung).

Aktivierung

Variable	Bedeutung
NEXARCH_DMS_APP_CMIS_ENABLED	true schaltet CMIS ein; sonst existiert keine CMIS-Route (404)
NEXARCH_DMS_APP_TENANT_SLUG	Pflicht, ist zugleich die Repository-ID
NEXARCH_DMS_APP_CMIS_PUBLIC_BASE_URL	optional, Basis der URLs in der Repository-Info (Standard: aus der Anfrage abgeleitet, inkl. /api/dms/v1)
NEXARCH_DMS_APP_CMIS_MAX_CONTENT_BYTES	optional, Obergrenze fuer createDocument (Standard 256 MiB)

Adressen

Alle unter /api/dms/v1/cmis/browser (Authentifizierung wie REST: Authorization: Bearer <Core-JWT>).

Adresse	Zweck
GET /cmis/browser	Repository-Infos
GET /cmis/browser/{repo}	Repository-Info (cmisselector=repositoryInfo, typeDefinition, typeChildren, typeDescendants) und objektbezogene Selektoren mit objectId
GET /cmis/browser/{repo}/root[/pfad]	Wurzel- bzw. Pfad-URL: cmisselector=object (Standard), children, parent, content
POST /cmis/browser/{repo}[/root/pfad]	cmisaction=createDocument (multipart, Teil content)

succinct=true liefert succinctProperties. maxItems und skipCount gelten fuer children. Die Wurzel (root) ist virtuell: sie enthaelt die Ordner und Dokumente ohne Elternordner.

Unterstuetzt

Repository-Info, die Typen cmis:document und cmis:folder, Objekt lesen (per ID und Pfad), Kinder auflisten, Elternordner, Inhalt lesen (Range-Anfragen moeglich), Dokument anlegen.

Nicht unterstuetzt (Antwort notSupported, 405)

Query, Aendern und Loeschen von Objekten, Ordner anlegen, Inhalt ersetzen, Versionierung (Check-out/-in), ACLs, Change-Log, Relationships, Renditions, getObjectParents, getDescendants/getFolderTree. AtomPub- und Web-Services-Binding gibt es nicht.

Abbildung auf die REST-API

CMIS	REST
Objekt (Ordner)	GET /folders/{id}
Objekt (Dokument)	GET /documents/{id}
Kinder	GET /folders/{id}/children und /documents (Wurzel: /folders/children, /folders/documents)
Inhalt	GET /documents/{id}/content (bei fertigem PDF-Derivat wird dieses geliefert, die Laenge in den Eigenschaften ist die des Originals)
createDocument	POST /uploads, PUT /uploads/{id}/chunk, POST /uploads/{id}/complete

Fehler: HTTP-Status wie in der REST-API, Koerper im CMIS-Format {"exception":"objectNotFound","message":"…"} plus dem Core-Fehlerobjekt error.

Grenzen

• Ein Objekt-Lookup per ID fragt zuerst den Ordner-, dann den Dokument-Endpunkt. Ein nicht vorhandenes Objekt liefert daher wie in REST 403 (Dokument-Guard), nicht 404.
• Dokumentlisten eines Ordners (/folders/.../documents) zeigen nur Dokumente des Aufrufers (Eigentuemer-Modell, INT-15); die Ordnerstruktur selbst ist mandantenweit sichtbar, bis Core-RBAC (Gruppen, RBAC-03) vorliegt. CMIS erbt beides unveraendert.
• Repository-Info und Typdefinitionen verlangen eine Anmeldung, aber keine Fachberechtigung. Die Anmeldung erzwingen dieselben Bausteine wie bei REST (Token-Pruefung der gemeinsamen Kette, im Uebergangsmodus der gemeinsame Guard); der CMIS-Code enthaelt keine eigene Pruefung, ein Test verbietet sie.
• Ein widerrufenes (nicht abgelaufenes) Token wird erst abgelehnt, wenn Core den Widerruf im Token-Vertrag bereitstellt (Core IAM-17); abgelaufene Token lehnt CMIS wie REST ab.
• Ein Test mit dem CMIS-Referenzclient (Apache Chemistry OpenCMIS) steht aus, siehe Pruefprotokoll.