Worum es geht
Du kennst die id eines Objekts und willst es lesen. Dafür hat jedes Modell zwei Endpunkte:
| Endpunkt | Körper | was zurückkommt |
|---|---|---|
POST {basis}/read/{id} | JSON mit response | genau die Felder, die du in response nennst |
GET {basis}/read/{id} | keiner | immer alles, was ["*"] liefert |
{basis} ist der Pfad des Modells, zum Beispiel /api/rest/hr/employee.
Die zwei Wege im Vergleich
POST /api/rest/hr/employee/read/7f3…
{ "response": ["firstname", "lastname"] }{
"data": {
"id": "7f3…",
"_createdOn": "2026-03-02 09:14:00",
"_updatedOn": "2026-09-01 16:40:12",
"firstname": "Daniel",
"lastname": "Mertins",
"company": null,
"department": null
},
"meta": { "error": false }
}id, _createdOn und _updatedOn kommen immer mit, auch wenn sie nicht in response stehen. Alles andere, was du nicht angefordert hast, steht als null in der Antwort. Mehr dazu unter Systemfelder.
GET /api/rest/hr/employee/read/7f3…{
"data": {
"id": "7f3…",
"firstname": "Daniel",
"lastname": "Mertins",
"company": { "id": "a1…", "companyname": null },
"department": { "id": "d4…", "name": null }
},
"meta": { "error": false }
}- du wählst die Felder in
response - Referenzen kannst du gezielt ausbauen
- du brauchst nur die Rollen der Modelle, die du wirklich anfragst
- kein Körper, CDMS nimmt immer
["*"] - Referenzen kommen nur mit ihrer
id - braucht die Leserolle jedes referenzierten Modells
Die Stationen einer Leseanfrage
Eine Leseanfrage läuft durch mehrere Prüfungen. Erst wenn alle bestanden sind, kommen Daten zurück:
-
CIASFilterketteIst das Token gültig?↳ nein 401
-
CDMSFeldauswahlSteht eine
responseim Körper?↳ nein 400 mitmessageKeyresponse -
CDMSModellrolleHat der Benutzer die Leserolle von
employee?↳ nein 403missing-permission|employee-read -
CDMSZeilenfilterGibt es das Objekt, und darf der Benutzer es sehen (Mandant, eigene Daten, Attributfilter)?↳ nein 404
not-found -
CDMSReferenzenHat der Benutzer die Leserolle jedes Modells, in das die
responsehineinreicht?↳ nein 403missing-permission|<rolle>, die ganze Anfrage scheitert - 200 mit den angeforderten Feldern
Zwei Dinge sind hier wichtig:
- Unsichtbar ist dasselbe wie nicht vorhanden. Ein Objekt, das es nicht gibt, und ein Objekt, das du nicht sehen darfst, liefern beide 404. So verrät CDMS nicht, dass es fremde Daten gibt. Siehe Warum Unsichtbares 404 liefert.
- Die
responsebestimmt, welche Rollen du brauchst. Liest du nur einfache Felder, reicht die Leserolle des Modells. Sobald dieresponsein eine Referenz hineinreicht, brauchst du auch die Leserolle des referenzierten Modells.
Alle Ausprägungen
Wann: Der Normalfall. Du weißt, welche Felder du brauchst.
-
1Client→CDMSschickt
POST /hr/employee/read/7f3…mit{ "response": ["firstname", "lastname"] } -
2CDMSlöst die
responsein eine Liste von Feldern auf -
3CDMSprüft die Leserolle von
employee -
4CDMS→Datenbanksucht die Zeile mit dieser
id, eingeschränkt durch die Zeilenfilter, und liest nur die angeforderten Spalten -
5HookLese-Hooks des Projekts sehen das Objekt, bevor es zur Antwort wird
-
6CDMS→Clientliefert das Objekt in
data
Ergebnis: 200 mit firstname, lastname und den Systemfeldern.
Wann: Du willst dir ein Objekt schnell ansehen, etwa mit curl oder im Browser.
Der Ablauf ist derselbe wie bei POST. CDMS setzt nur selbst response auf ["*"]. Du bekommst alle einfachen Felder und jede Referenz mit ihrer id. Dafür brauchst du die Leserolle jedes referenzierten Modells.
Ergebnis: 200 mit allem, was * liefert, oder 403, wenn eine Referenzrolle fehlt.
Wann: Das Modell hat genau ein Objekt, z. B. Einstellungen. Pfad ohne id: POST /read bzw. GET /read.
-
1Client→CDMSschickt
POST /crm/einstellungen/readmit{ "response": ["+"] } -
2CDMS→Datenbanksucht das eine Objekt selbst, mit den Zeilenfiltern
-
3CDMS→Clientkeins da → 404
no-object-found -
4CDMS→Clientvorhanden → liest es wie ein normales Objekt
Ergebnis: 200 mit dem einen Objekt. Siehe Singletons.
Wann: Du liest über die Hub-API eines abstrakten Modells, z. B. /crm/kunde/read/{id}.
-
1Client→CDMSschickt nur die
id, kein@type -
2CDMS→Datenbankliest den gespeicherten Typ zur
idnach, z. B.crm.privatkunde -
3CDMSgibt die Anfrage an die API des Untertyps weiter, mit dessen Rollen und Filtern
-
4CDMS→Clientliefert das Objekt mit
@type
Ergebnis: 200 mit den Feldern des Untertyps und "@type": "crm.privatkunde". Siehe Abstrakte Modelle.
Wann: Dem Benutzer fehlt die Rolle employee-read.
-
1Client→CDMSschickt eine gültige Leseanfrage
-
2CDMSprüft die Leserolle von
employee -
3CDMS→ClientRolle fehlt → 403
missing-permission|employee-read
Ergebnis: 403. Die Datenbank wird gar nicht erst gefragt.
Wann: Die id gibt es nicht, oder das Objekt gehört einem anderen Benutzer bzw. fällt durch einen Attributfilter.
-
1CDMS→Datenbanksucht die Zeile mit
idund allen Zeilenfiltern -
2CDMS→Clientkeine Zeile gefunden → 404
not-found
Ergebnis: 404. Für den Client ist nicht zu unterscheiden, ob es das Objekt nicht gibt oder ob er es nicht sehen darf.
Entscheidungstabelle
| response im Körper | Rolle employee-read | Objekt sichtbar | Rollen der angefragten Referenzen | Antwort |
|---|---|---|---|---|
| nein | – | – | – | 400 response |
| ja | nein | – | – | 403 missing-permission|employee-read |
| ja | ja | nein | – | 404 not-found |
| ja | ja | ja | fehlt eine | 403 missing-permission|<rolle> |
| ja | ja | ja | alle da oder keine angefragt | 200 |
Die Tabelle beschreibt den Standard, den Strict Mode. Ist er ausgeschaltet, ändern sich Status und Schlüssel: Ohne employee-read kommt 404, und eine Einzelreferenz ohne Rolle ist still null. Siehe Strict Mode.
Fallen
Wie es weitergeht
- Was in
responsestehen darf: Feldauswahl mitresponse - Viele Felder auf einmal: Wildcards + und *
- Referenzen vollständig laden: Referenzen und Listen ausbauen
- Die drei Fehlercodes im Vergleich: 401, 403 oder 404?