Worum es geht
Jede Anfrage, die Daten zurückliefert, trägt eine Liste response. Sie sagt CDMS, welche Felder in der Antwort stehen sollen. Das gilt für read, query, create, update, patch und rollback.
{
"response": ["id", "firstname", "+", { "field": "company", "response": ["companyname"] }],
"exclude": ["internalNote"]
}
Die drei Arten von Einträgen
Ein Eintrag in response ist entweder ein Text oder ein Objekt:
flowchart TB
E["Eintrag in response"] --> T{"Text oder Objekt?"}
T -->|"Text ohne + und *"| F["Feldname<br/>genau dieses einfache Feld"]
T -->|"Text mit + oder *"| W["Wildcard<br/>viele Felder auf einmal"]
T -->|"Objekt { field, response }"| O["Referenz ausbauen<br/>mit eigener Feldauswahl"]
| Eintrag | Beispiel | liefert |
|---|---|---|
| Feldname | "firstname" | genau dieses einfache Feld |
| Wildcard | "+", "*", "+name", "depart*" | alle passenden Felder, siehe Wildcards |
| Objekt | { "field": "company", "response": ["companyname"] } | die Referenz company mit ihrer eigenen Feldauswahl |
Dazu kommt neben response die Liste exclude. Sie nimmt Felder wieder heraus, die eine Wildcard dazugenommen hat.
Das Objekt im Detail
Ein Objekt baut eine Referenz aus. Es hat bis zu vier Schlüssel:
| Schlüssel | Pflicht | Bedeutung |
|---|---|---|
field | ja | Name der Referenz im Modell, z. B. company oder employees |
response | ja | Feldauswahl für das referenzierte Objekt, mit denselben drei Arten von Einträgen |
exclude | nein | wie oben, aber nur für diese Ebene |
parameter | nein | nur bei Listen: Filter, Sortierung, Seitengröße für die Einträge der Liste |
Weil response im Objekt wieder Objekte enthalten darf, kannst du beliebig tief verschachteln. Wie das abläuft, steht unter Referenzen und Listen ausbauen.
Beispiel am Modell employee
Dasselbe Modell wie auf den anderen Seiten dieses Kapitels: employee mit firstname, lastname und den Referenzen company und department.
POST /api/rest/hr/employee/read/7f3…
{
"response": [
"firstname",
"+name",
{ "field": "company", "response": ["companyname"] }
]
}{
"data": {
"id": "7f3…",
"firstname": "Daniel",
"lastname": "Mertins",
"company": { "id": "a1…", "companyname": "Codamic AG" },
"department": null
},
"meta": { "error": false }
}firstname steht doppelt da, einmal als Name und einmal über +name. Das schadet nicht, CDMS liest jedes Feld nur einmal.
Was CDMS mit ungewöhnlichen Einträgen macht
Wann: Der Körper ist {} oder enthält nur exclude.
-
1Client→CDMSschickt
POST /read/{id}ohneresponse -
2CDMS→Client400
InvalidQueryDefinitionExceptionmitmessageKeyresponse
Ergebnis: 400. Dasselbe gilt für ein Objekt { "field": … } ohne eigene response.
Wann: { "response": [] }
Eine leere Liste ist erlaubt. CDMS liest dann nur, was es immer liest: id, _createdOn und _updatedOn.
Ergebnis: 200 mit den Systemfeldern, alles andere null. Praktisch, wenn du nur wissen willst, ob es das Objekt gibt und du es sehen darfst.
Wann: Du schreibst "fristname" statt "firstname", oder das Feld gibt es in diesem Modell nicht.
-
1CDMSfindet zu dem Namen keine Spalte
-
2CDMSlässt den Eintrag weg, ohne Fehler
-
3CDMS→Clientliefert alle anderen Felder
Ergebnis: 200. Das falsch geschriebene Feld fehlt einfach, das richtige steht als null da.
Wann: { "field": "firma", "response": ["+"] }, aber die Referenz heißt company.
CDMS findet firma nicht im Modell und überspringt das ganze Objekt.
Ergebnis: 200 ohne diese Referenz.
Wann: { "field": "firstname", "response": ["+"] }
firstname ist keine Referenz und lässt sich nicht ausbauen. CDMS überspringt das Objekt.
Ergebnis: 200, firstname wird dabei nicht geliefert. Nenne es als Text.
Wann: Die response reicht in company, dem Benutzer fehlt company-read.
-
1CDMSprüft beim Ausbauen die Leserolle von
company -
2CDMS→Client403
missing-permission|company-read
Ergebnis: 403 für die ganze Anfrage, nicht nur für die Referenz.
Entscheidungstabelle
| Eintrag | im Modell vorhanden | Leserolle des Zielmodells | Ergebnis |
|---|---|---|---|
response fehlt | – | – | 400 response |
| Feldname | ja | – | Feld wird geliefert |
| Feldname | nein | – | still weggelassen, 200 |
| Wildcard | – | – | alle passenden Felder, auch keins ist 200 |
| Objekt auf Referenz | ja | ja | Referenz mit eigener Feldauswahl |
| Objekt auf Referenz | ja | nein | 403 missing-permission|<rolle> |
| Objekt auf Referenz | nein | – | still übersprungen, 200 |
| Objekt auf einfachem Feld | ja | – | still übersprungen, 200 |
Rechte: pro Modell und pro Beziehung
Ob du etwas lesen darfst, entscheidet CDMS pro Modell und pro Beziehung. Wer employee lesen darf, darf die einfachen Felder von employee lesen, außer ein Feld trägt eine eigene Leserolle: Dann lässt + es ohne diese Rolle weg, und beim Namen angefordert gibt es 403. Siehe Geschützte Werte. Eine Rolle kommt erst ins Spiel, wenn die response in ein anderes Modell hineinreicht: Dann brauchst du dessen Leserolle oder eine Rolle auf der Beziehung selbst. Siehe Modellrollen und Rechte auf Beziehungen.
Die Tabellen oben beschreiben den Standard, den Strict Mode. Ohne ihn ist eine Einzelreferenz ohne Rolle still null; die anderen Fälle scheitern weiter, nur mit anderem Status oder Schlüssel. Siehe Strict Mode.