Dieses Topic beschreibt den besonderen Eingabetyp Client-Objekt (ASObject) für REST-API-Endpunkte. Eine Übersicht über die REST API-Konfiguration finden Sie unter REST API.
Client-Objekt als Eingabetyp wählen
Wenn Sie als Eingabetyp den Typ Client-Objekt (ASObject) wählen, erscheint rechts neben dem Auswahlfeld/Combobox-Element ein Button Client-Objektstruktur. Damit definieren Sie eine Client Objekt-Struktur Referenz im Feld clientStructure.
Der Klick auf den Button öffnet ein Popover-Element. Dort wählen Sie eine vorhandene private oder öffentliche Client-Objektstruktur aus oder legen eine neue lokal an.
Neue Client-Objektstruktur anlegen
Mit der Auswahl Neue Client-Objektstruktur erscheint ein Element zur Definition der neuen Struktur. Optional geben Sie in einem weiteren Popover einen Alias für die Kopfdaten an. Der Alias muss den Anforderungen für Klassennamen genügen.
Die Option Ignoriere zusätzliche Eigenschaften entscheidet, ob die zur Laufzeit bereitgestellte Datenstruktur Felder enthalten darf, die in der Struktur nicht explizit definiert sind. Details unter Client Objekt-Struktur (Definition).
Beispiel: Client-Objektstruktur „Aerodrome"
Über einen API-Endpunkt mit der POST-Methode importieren Sie Stammdaten für Landeplätze in die Lobster Data Platform.
Ein Landeplatz lässt sich optional über einen ICAO-Code (4-Buchstaben-Kennung wie EGLL für London/Heathrow) und einen IATA-Code (3-Buchstaben-Kennung wie LHR) identifizieren. Zusätzlich oder ersatzweise enthält das im JSON-Format erwartete Datenobjekt weitere Merkmale: Geokoordinaten, w3w, Klartexte und so weiter.
Die lokale Client-Objektstruktur mit dem Alias Aerodrome definiert dafür die optionalen Felder icaoCode und iataCode. Die Option Ignoriere zusätzliche Eigenschaften bleibt deaktiviert (Standard).
Zur Laufzeit antwortet die Plattform mit HTTP-Fehler 404 Error: Not Found, wenn der Endpunkt ein Datenobjekt mit unbekanntem Feldnamen erhält. Folgende Struktur wäre also nicht als Aerodrome-Eingabewert akzeptiert:
{"icaoCode":"VHHH","iataCode":"HKG","name":"Hong Kong Intl.","aka":"Chek Lap Kok"}
Aktivieren Sie Ignoriere zusätzliche Eigenschaften, erscheint in der Felder-Liste zusätzlich das Symbol *. Es zeigt an, dass weitere Felder mit beliebigen Namen erlaubt sind.
Ohne „Ignoriere zusätzliche Eigenschaften" | Mit „Ignoriere zusätzliche Eigenschaften" |
|---|---|
|
|
HINWEIS Die zugehörige OpenAPI-Beispielstruktur enthält stattdessen ein Feld, dessen Name dem Schema additionalProp<index> entspricht, zum Beispiel additionalProp1.
Der Endpunkt akzeptiert nun auch ein Datenobjekt wie {"designation":"CVN-65", "name":"USS Enterprise"} als Aerodrome-Eingabewert. Es enthält Felder, die in der Client-Objektstruktur nicht deklariert sind.
HINWEIS Ignoriere zusätzliche Eigenschaften: Dies betrifft nur die Akzeptanz des Datenobjekts als Eingabetyp. Die Plattform entfernt die zusätzlichen Felder nicht aus dem Datenobjekt. Sie können im Aktionsblock weiterhin darauf zugreifen.
Für den Zugriff über den Objekt-Feld-Wertauflöser geben Sie einen konkreten Feldnamen (hier designation) als Freitext an. Mehrere Feldnamen probieren Sie über verkettete Standardwert-Wertauflöser durch.
Alternativ behandeln Sie den Typ Client-Objekt als Map. Der Alle Map-Schlüssel-Wertauflöser ermöglicht die systematische Auswertung aller vorhandenen Feldnamen.
Eingabetyp „Client-Objekt" für HTML-Formulardaten
Ein Request mit dem Content-Type-Header application/x-www-form-urlencoded liefert Daten aus einem HTML-Formular. Diese Daten kommen als Verkettung von Schlüssel-Wert-Paaren in einem URL-codierten String an.
Diese Daten verarbeiten Sie mit dem Eingabetyp Client-Objekt. Die folgende Tabelle zeigt die Interpretation der Syntax an Beispielen:
HTTP-Formulardaten | Client-Objekt (JSON) |
|---|---|
|
|
|
|
|
|