GraphQL-API

GraphQL ist optional. Die HTTP-API und der WebSocket-Kanal decken bereits jede Operation ab - diese Seite richtet sich an Services, die einen einzigen Endpunkt mit typisierter Abfragesprache bevorzugen. Sende eine Query per POST an /xapi2/graphql mit demselben Bearer-Token wie an den Rest der API und du bekommst dieselben Daten zurück, nur in einem GraphQL-Antwort-Format. Hinter der Leitung läuft dieselbe Infrastruktur wie bei HTTP und WebSocket - der GraphQL-Endpunkt ist eine dünne Schicht obendrauf, kein paralleles System. Authentifizierung, PAT-Berechtigungsumfang, Anfragelimits pro IP und pro Token, Zeilen-Zugriffsprüfungen, Audit-Logging, Validierungsregeln, Plan-Kontingente und die Live-Verteilung an verbundene WebSocket-Clients laufen über *exakt dieselben Codepfade* wie die REST-Endpunkte. Ein Fix oder eine neue Regel greift in allen drei gleichzeitig. Das Schema selbst ist bewusst kompakt: ein einziger Object-Typ, dessen Inhalt als JSON-Skalar reist, plus sechs Wurzelfelder (object, objects, createObject, updateObject, deleteObject). Felder pro Modell stehen auf der jeweiligen Modell-Seite - sie bleibt die verbindliche Quelle dafür, welche Daten eine Zeile trägt.

So funktioniert's

Sicherheit

Der GraphQL-Endpunkt nutzt dieselbe Infrastruktur wie die HTTP-API und der WebSocket-Kanal - er ist eine dünne Schicht obendrauf, kein paralleles System. Authentifizierung, PAT-Berechtigungen, Anfragelimits, Zeilen-Zugriffsprüfungen, Audit-Log und Live-Verteilung an WebSocket-Clients laufen über exakt dieselben Codepfade. Was per REST nicht erlaubt ist, ist per GraphQL ebenso nicht erlaubt - eine "GraphQL-Hintertür" gibt es nicht. Genaue Regeln pro Modell siehe die jeweilige Modell-Seite.

Schema

Das Schema ist klein gehalten - eine Object-Form mit JSON-Inhalt plus sechs Wurzelfeldern. Felder pro Modell stehen auf der entsprechenden Modell-Seite.

scalar JSON

type Object {
  id:         ID!
  type:       String!
  status:     String
  ownedBy:    ID
  createdBy:  ID
  updatedBy:  ID
  appSlug:    String
  data:       JSON
  createdAt:  String
  updatedAt:  String
  isArchived: Boolean
}

type ObjectList {
  data:    [Object!]!
  count:   Int!
  hasMore: Boolean!
  limit:   Int
  offset:  Int
  sort:    String
  appSlug: String
  total:   Int
}

type DeleteResult { ok: Boolean!, id: ID! }

type Query {
  object  (type: String!, id: ID!): Object
  objects (
    type: String!,
    limit: Int, offset: Int, after: ID,
    sort: String, q: String,
    withCount: Boolean, filters: JSON,
  ): ObjectList!
}

type Mutation {
  createObject (type: String!, input: JSON!):           Object!
  updateObject (type: String!, id: ID!, input: JSON!):  Object!
  deleteObject (type: String!, id: ID!):                DeleteResult!
}

Beispiele

curl -X POST https://www.ki-bewerber-management.de/xapi2/graphql \
  -H "Authorization: Bearer pat_…" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "query($t:String!,$id:ID!){ object(type:$t,id:$id){ id data } }",
    "variables": { "t": "application", "id": "<object-id>" }
  }'

Grenzen

Ein einzelnes Dokument ist auf folgende Werte begrenzt - bequem oberhalb jeder realistischen Dashboard-Komposition. Diese Grenzen halten die Worst-Case-Kosten einer Query vorhersehbar.

Bewusst nicht unterstützt