DataSnap-REST-Nachrichtenprotokoll
Nach oben zu DataSnap-REST
Dieses Thema beschreibt das REST-Nachrichtenprotokoll für DataSnap, das den Remote-Aufruf von Servermethoden sowie die Registrierung von Heavyweight-Callbacks ermöglicht. Anhand der Informationen in diesem Thema können Sie in jeder beliebigen Sprache Clients implementieren, die mit einem DataSnap-Server über HTTP-Anforderungen kommunizieren können.
Inhaltsverzeichnis
Remote-Methodenaufruf
Wenn ein DataSnap-Server über eine aktive Komponente zur Behandlung von HTTP-Verbindungen verfügt, wird ein Nachrichtenprotokoll bereitgestellt, wobei HTTP-Anforderungen an den Server gesendet werden können, um public-Methoden einer für den Server mit einer TDSServerClass-Komponente registrierten Klasse aufzurufen. Am einfachsten rufen Sie eine Servermethode über eine GET-Anforderung mit dem folgenden URL und ohne Inhalt im Nachrichtenrumpf auf:
http://host:port/datasnap/rest/[ClassName]/[MethodName]/[ParamValue]
Port und ParamValue sind optional. "datasnap" und "rest" sind gewissermaßen auch optional und müssten – abhängig von den Werten der Eigenschaften DSContext und RESTContext für die HTTP-Verbindung auf dem Server – geändert werden.
Parameter in dem URL
ParamValue repräsentiert eine durch Schrägstrich (/) getrennte Liste mit Parameterwerten, die den für die aufzurufende Servermethode erforderlichen Eingabeparametern entsprechen. Wenn die Servermethode (Funktion/Prozedur) keine Eingabeparameter hat, dann darf hinter dem Methodennamen in dem URL nichts mehr stehen. Durch zwei Schrägstriche (//) im Abschnitt des URLs, der die Parameterwerte repräsentiert, wird der Wert des Parameters an dieser Indexposition auf einen leeren String gesetzt.
Die auf diese Weise übergebenen Werte müssen URL-sicher verschlüsselt sein, was auch für die Verschlüsselung von Unicode-Zeichen gilt. Werte mit einer JSON-Objekt- oder JSON-Array-Repräsentation dürfen nicht auf diese Weise übergeben werden: sie müssen im Rumpf der HTTP-Anforderung übergeben werden, und der Anforderungstyp muss POST oder PUT sein.
Parameter im Anforderungsrumpf
Wenn Sie eine Servermethode aufrufen möchten, die einen nicht von einer GET- oder DELETE-Anforderung unterstützten Eingabeparameter hat (z.B. ein Parameter, der nicht als String, Zahl, Boolean oder Null dargestellt werden kann), oder wenn Sie einfach einen oder mehrere Parameter im Inhalt der Anforderung übergeben möchten, müssen Sie den Anforderungstyp POST oder PUT verwenden.
Wenn Sie beispielsweise eine Servermethode wie die folgende aufrufen möchten:
function TServerMethods1.updateEchoAttribute(Key: String; Obj: TJSONObject): String;
Dann sollte Ihre Anforderung folgendermaßen lauten:
POST /datasnap/rest/TServerMethods1/EchoAttribute/Attr1 HTTP/1.1
....*additional headers*...
Accept: application/json
Content-Type: text/plain;charset=UTF-8
{"Attr1":"ValueToReturn"}
Diese Anforderung enthält einige Einträge, die näher erläutert werden müssen. Beachten Sie zunächst, dass der übergebene Methodenname "EchoAttribute" und nicht "updateEchoAttribute" lautet. Standardmäßig wird nämlich das Präfix "update" jeder Methode zugeordnet, die mit POST aufgerufen wird. Ebenso wird das Präfix "cancel" für DELETE-Anforderungen und das Präfix "accept" für PUT-Anforderungen verwendet. Diese Art der Präfixverwendung kann durch Setzen des Methodennamens in Anführungszeichen vermieden werden. Die erste Zeile der Anforderung würde dann folgendermaßen lauten:
POST /datasnap/rest/TServerMethods1/%22updateEchoAttribute%22/Attr1 HTTP/1.1
Diese Anforderung ruft auch die updateEchoAttribute-Servermethode auf, aber die Anführungszeichen verhindern, dass ein zusätzliches "update" vor den angegebenen Servernamen gesetzt wird. Das Setzen des Methodennamens in Anführungszeichen ermöglicht zudem den Aufruf von Servermethoden mit POST, PUT oder DELETE, denen keine dem Anforderungstyp entsprechenden Namen vorangestellt werden. Falls die Servermethode zum Beispiel folgendermaßen lautet:
function TServerMethods1.EchoAttribute(Key: String; Obj: TJSONObject): String;
Dann wäre das Setzen des Methodennamens in Anführungszeichen erforderlich, da der Wert eines TJSONObject in dem Anforderungs-URL nicht unterstützt wird. Das heißt, eine GET-Anforderung, der einzige Anforderungstyp, der standardmäßig kein Methodenpräfix voraussetzt, kann nicht verwendet werden. Die POST-Anforderung würde folgendermaßen lauten:
POST /datasnap/rest/TServerMethods1/%22EchoAttribute%22/Attr1 HTTP/1.1
All diese Beispiele haben dasselbe Ergebnis, wobei die Servermethode mit "Attr1" als Wert des Parameters Key aufgerufen wird und der Wert von Obj ein JSON-Objekt ist, das eine Eigenschaft "Attr1" und einen zugehörigen Wert hat. Der Inhalt der Antwort enthält das Ergebnis des Aufrufs der Servermethode, das in diesem Beispiel der String "ValueToReturn" wäre.
Wenn Sie mehrere Parameterwerte in dem Anforderungsinhalt übergeben möchten, müssen Sie sie in der richtigen Reihenfolge in ein JSON-Array setzen, und dieses Array als Wert eines JSON-Objektpaars mit dem Schlüsselwort "_parameters" angeben. Das JSON-Ergebnisobjekt muss als String dargestellt und folgendermaßen als Inhalt der Anforderung gesetzt werden:
{"_parameters":["Param1", "Param2"]}
Bei diesem Format werden zuerst die Eingabeparameter aus dem Anforderungs-URL und dann die übrigen Eingabewerte der Reihenfolge nach aus dem Array _parameters übernommen.
In der Anforderung sind Abfrageparameter zulässig. Der Benutzer erhält dann aus Servermethoden Zugriff auf die im URL übergebenen Abfrageparameter durch Abrufen der Aufrufs-Metadaten (mit einem Aufruf von GetInvocationMetadata() nach dem Hinzufügen der DBXPlatform zu der uses-Klausel) und Zugreifen auf die Liste der gespeicherten Parameter. Dem HTTP-Dienst des Servers wurde das Ereignis FormatResult hinzugefügt, mit dem die JSON-Antwort in einem beliebigen Format für Methodenaufrufe zurückgegeben werden kann.
Aufrufantwort
Die von einer Aufrufanforderung zurückgegebene Antwort hat einen Antworttext, der eine String-Repräsentation eines JSON-Objekts ist, das etwa folgendermaßen aussieht:
{"result":["ValueToReturn"]}
Bei korrektem Zerlegen in eine JSON-Objektinstanz können Sie für die Eigenschaft "result" das JSON-Array ermitteln. Dieses Array enthält die Werte für alle Parameter in der Reihenfolge ihrer Anordnung in der Signatur der Servermethode, die zurückgegeben werden (out, var, Ergebnistypen). Das Ergebnis ist immer der letzte Eintrag in dem Array, und in diesem Beispiel ist es ein JSON-String mit dem Wert, der von der Implementierung der Servermethode EchoAttribute zurückgegeben würde.
Wenn während des Aufrufs auf dem Server ein Fehler auftritt, wie z.B. eine abgelaufene Sitzung, ein unbefugter Benutzer oder ungültige Eingabewerte, dann enthält das zurückgegebene JSON-Objekt anstatt einer "result"-Eigenschaft eine "error"- oder "SessionExpired"-Eigenschaft, wie die folgende:
{"SessionExpired":"Die angegebene Sitzung ist abgelaufen, weil sie inaktiv war oder eine ungültige Sitzungs-ID hatte"}
Festlegen des Stream-Antworttyps
Wenn das Ergebnis eines Methodenaufrufs ein TStream-Objekt ist, dann kann der Stream entweder als JSON-Array oder als Inhalts-Stream der Antwort zurückgegeben werden. Mit dem URL-Parameter "json" können Sie folgendermaßen festlegen, ob ein JSON-Array oder ein Inhalts-Stream zurückgegeben werden soll:
http://host:port/datasnap/rest/[Class]/[Method]/?json=true
Sie können den Wert auf "True" oder "False" setzen. Bei "True" wird das Ergebnis immer als JSON-Array zurückgegeben. Bei "False" wird das Ergebnis als Inhalts-Stream zurückgegeben, sofern keine anderen var/out/result-Parameter zurückgegeben werden.
Authentifizierung
Wenn für den Server eine Authentifizierung erforderlich ist, dann müssen Sie im "Autorisierungs"-Header der Anforderung Ihre Authentifizierungsdaten (Benutzername und Passwort) korrekt formatiert übergeben. Dies ist aber nur erforderlich, wenn Sie keine Sitzungs-ID in der Anforderung angeben. Das Format des Wertes des Autorisierungs-Headers lautet:
Basic base64(Benutzer:Passwort)
Oder, falls der Benutzername beispielsweise "admin" und das Passwort ebenfalls "admin" ist:
Basic YWRtaW46YWRtaW4=
Der String für die base64-Kodierung muss ein einzelner String sein, der den Namen und das Passwort durch Doppelpunkt getrennt enthält.
Anforderungsfilter
DataSnap verwendet zum Filtern von Ergebnissen das Konzept der Anforderungsfilter. Diese vordefinierten Filter verbinden in eine API, mit der in dem URL die Filter für den jeweiligen Parameter und die an diesen Filter zu übergebenden Werte festgelegt werden können. Eine Serverfunktion könnte z.B. einen sehr großen String zurückgeben, wovon Sie aber möglicherweise nur die ersten Zeichen benötigen. In diesem Fall können Sie mit dem SubString-Filter den Bereich des Strings festlegen, an dem Sie interessiert sind. Das folgende Beispiel ist ein URL für eine Serverfunktion mit einem einzelnen Eingabeparameter und einem String-Ergebnis:
http://host:port/datasnap/rest/[Class]/[Method]/[ParamValue]?ss.r=1,3
Der Teil nach dem "?" definiert, welcher Filter für welche(n) Parameter verwendet werden soll. In diesem Fall wird für den Rückgabe-String (wenn kein Parameterindex angegeben ist, wird der Filter auf das Ergebnis angewendet) mit der Bereichsfunktion des SubString-Filters festgelegt, dass das Ergebnis ein aus drei Zeichen bestehender Teilstring sein soll, der mit dem zweiten Zeichen des Ergebnisses beginnt.
Weitere Informationen finden Sie unter Anforderungsfilter.
Sitzungsinformationen
Wenn Sie eine Servermethode aufrufen, die Sie nicht in einer Sitzungs-ID der Anforderung übergeben haben, wird eine neue Sitzung auf dem Server erstellt, und die Sitzungs-ID wird in dem "Pragma"-Header bereitgestellt. Der für diesen Header gespeicherte Wert enthält zwei Schlüssel, "dssession" und "dssessionexpires". Der erste ist die ID der Sitzung auf dem Server und der zweite ist eine Schätzung der verbleibenden Millisekunden bis zum Ablauf der Sitzung. Wenn "dssessionexpires" nicht angegeben oder ein negativer Wert ist, dann läuft die Sitzung nicht ab und muss geschlossen werden, wenn sie vom Client nicht mehr benötigt wird. Die Sitzungs-ID müssen Sie in dem "Pragma"-Header jeder weiteren Anforderung im folgenden Format übergeben:
dssession=[Sitzungs-ID]
Anhand der Millisekunden bis zum Sitzungsablauf können Sie feststellen, ob die Sitzungs-ID nicht mehr gültig ist und entscheiden, sie nicht mit künftigen Anforderungen zu übergeben, weil sie wahrscheinlich ungültig wäre und einen SessionExpired-Fehler liefern würde. Wenn Sie ein SessionExpired-Ergebnis vom Server erhalten, müssen Sie die gespeicherte Sitzungs-ID löschen und zulassen, dass der Server bei der nächsten Anforderung eine neue ID vergibt.
Um die Sitzung vor deren Ablauf zu schließen, führen Sie eine GET-Anforderung mit dem folgenden URL aus und übergeben im Pragma-Header der Anforderung die Sitzungs-ID, wie oben erläutert:
http://host:port/datasnap/rest/CloseSession/
Damit wird die Sitzung mit der angegebenen ID beendet und bei Erfolg der folgende Antworttext zurückgegeben (bei Misserfolg wird die SessionExpired-Meldung zurückgegeben):
{"result":[true]}
Zwischenspeicherung von Sitzungsparametern
Eine Verwendung für Sitzungen auf dem Server ist die optionale Speicherung von Parameterwerten aus früheren Aufrufen, damit Ergebnisse eines Methodenaufrufs mehrfach abgerufen werden können, ohne dass die Methode selbst erneut aufgerufen werden muss. Parameter, für die eine JSON-Objekt- oder JSON-Array-Repräsentation erforderlich ist, wie z.B. Streams und benutzerdefinierte Typen, können im Zwischenspeicher gespeichert werden.
Um festzulegen, dass der Zwischenspeicher verwendet werden soll, müssen Sie in der Anforderung den Header-Wert "Accept" auf "application/rest" setzen. Wenn Sie eine Servermethode aufrufen, deren Ergebnis beispielsweise ein TJSONObject ist, wird ein neuer Zwischenspeichereintrag erstellt, der den Zugriff auf das JSON-Ergebnisobjekt ermöglicht. Der vom Aufruf zurückgegebene Wert hat die folgende Form:
{"result":["0/0/0"],"cacheId":0,"cmdIndex":0}
"0/0/0" steht an der Stelle, an der das tatsächliche Aufrufergebnis erscheinen würde. Dabei handelt es sich um den Bezeichner und den relativen Pfad zu dem jeweiligen Eintrag im Zwischenspeicher. Das Format dieses relativen Pfades kann folgendermaßen interpretiert werden:
[Zwischenspeicher-Eintrags-ID]/[Befehlsindex]/[Parameterindex]
Zwischenspeicher-Eintrags-ID ist der eindeutige Bezeichner für den Methodenaufruf, den Sie ausführen. Nur Ausführungen, die Ergebnisse im Zwischenspeicher speichern, erhalten eindeutige Bezeichner. Befehlsindex gibt an, zu welchem Befehl der Ausführung das Ergebnis gehört. Dies ist nur ein Wert ungleich Null, wenn es sich um eine Stapelausführung (gleichzeitig mehrere Servermethoden) handelt. Parameterindex ist der Index des komplexen Parameters, der zurückgegeben werden soll. Der Index beginnt bei Null und basiert auf den komplexen Parametern des Befehls, nicht auf allen Parametern des Befehls.
Die weiteren Werte von "cacheId" und "cmdIndex" sind dieselben Werte, die als die ersten beiden Zahlen in "0/0/X" erscheinen. Wenn für den Methodenaufruf mehr als ein zwischengespeichertes Ergebnis vorhanden ist, enthält das Array "result" mehrere Einträge, die aber alle die "cacheId"- und "cmdIndex"-Werte gemeinsam nutzen, da sie Teil desselben zwischengespeicherten Eintrags und Ergebnisse desselben Methodenaufrufs sind.
Mit diesen relativen Pfaden erstellen Sie einen Zwischenspeicher-URL. Der Zwischenspeicher-URL verwendet "cache" (CacheContext) anstelle von "rest" (RESTContext), und ihm wird dann der im Aufrufergebnis zurückgegebene relative URL nachgestellt.
Zwischenspeicher-URLs unterstützen die Anforderungstypen GET und DELETE. Wenn GET gesendet wird, sind die folgenden URLs verfügbar:
|
http://host:port/datasnap/cache |
Gibt ein JSON-Objekt zurück, das den Inhalt des Zwischenspeichers beschreibt. |
|
http://host:port/datasnap/cache/(CacheID) |
Gibt ein JSON-Objekt zurück, das das Zwischenspeicherungsobjekt mit der angegebenen ID beschreibt. |
|
http://host:port/datasnap/cache/(CacheID)/(CmdIndex) |
Gibt eine JSON-Repräsentation des angegebenen Befehls zurück. |
|
http://host:port/datasnap/cache/(CacheID)/(CmdIndex)/(ParameterIndex) |
Gibt den tatsächlichen Parameter als JSON oder Stream zurück. |
Bei einem DELETE-Befehl werden die folgenden URLs unterstützt:
| http://host:port/datasnap/cache | Löscht alle zwischengespeicherten Einträge. |
| http://host:port/datasnap/cache/(CacheID) | Löscht den zwischengespeicherten Eintrag und alle zugehörigen Befehle/Parameter. |
Wenn Sie den Zwischenspeicher nicht leeren, wird er beim Ablauf der Sitzung geleert und freigegeben. Weitere Informationen finden Sie unter Zwischenspeicherung von DBX-Parametern.
Heavyweight-Callbacks
Heavyweight-REST-Callbacks ermöglichen einem Client eine HTTP-Anforderung mit langen Ausführungszeiten zu senden, die sich wie eine beim Server registrierte Callback-Funktion verhält. Der Anforderung sind Informationen zugeordnet, die dem Server mitteilen, wie er zu antworten hat. Wird eine Antwort abgerufen, wird eine neue Anforderung an den Server gesendet, um die Callback-Funktion zurück in einen empfangsbreiten Zustand zu versetzen.
Registrieren einer Heavyweight-Callback-Funktion (Client-Kanal)
Die ursprüngliche Anforderung, die das Heavyweight-Callback-Handshake startet, sollte folgendermaßen formatiert und als GET-Anforderung gesendet werden:
http://host:port/datasnap/rest/DSAdmin/ConsumeClientChannel/[SCN]/[CHID]/[CBID]/[SCNS]/[ST]//
Mit diesem Handshake wird eigentlich eine Callback-Funktion registriert, die selbst eine oder mehrere Callbacks enthält, zu denen sie verzweigt. SCN ist der Name des Serverkanals, für den diese Callback-Funktion empfangsbereit sein soll. Dieser Wert kann alles sein, was der Server möglicherweise senden oder mitteilen kann. SCNS ist eine durch Komma getrennte Liste der Kanalnamen des Servers für die registrierte Callback-Funktion. Diese Liste kann leer (die Callback-Funktion verwendet einfach den ServerChannelName des Kanals) oder eine Liste sein, die dem ServerChannelName des Kanals hinzugefügt wird. Weitere Informationen dazu finden Sie in der DocWiki-Dokumentation über Heavyweight-REST-Callbacks. Wenn der Server etwa folgendermaßen sendet:
Val := TJSONString.Create(Memo1.Text);
[DSServer].BroadcastMessage('MemoChannel', Val);
Dann soll der Wert von SCN als "MemoChannel" übergeben werden, damit Sie diesen speziellen Broadcast empfangen können.
CHID ist eine eindeutige ID für den Callback-Kanal des Clients. Dies kann Verschiedenes sein, aber der Aufruf schlägt fehl, wenn CHID nicht für die bereits auf dem Server vorhandenen Werte eindeutig ist. CBID ist eine eindeutige ID für die erste Callback-Funktion des Callback-Kanals des Clients. Weil ein Callback-Kanal immer mindestens eine Callback-Funktion enthalten muss, ist dieser Parameter erforderlich. Weitere untergeordnete Callbacks können später registriert werden. ST ist ein Sicherheits-Token, das Sie hier definieren. In allen künftigen Aufrufen zur Änderung des Client-Kanals, wie z.B. Hinzufügen oder Entfernen von Callbacks, müssen Sie dieses Sicherheits-Token angeben, um sich bei dem zu modifizierenden Kanal zu validieren. Der letzte Parameter (//) wird beim Registrieren des Kanals als leerer String übergeben.
Wenn die Registrierung erfolgreich erstellt wurde, wird sofort eine Antwort zurückgegeben, die etwa folgendermaßen aussieht:
{"result":[{"invoke":["cb12345",{"created":true},1]}]}
"cb12345" ist dabei die eindeutige ID der Callback-Funktion, die bei der Erstellung des Client-Kanals (CBID) registriert wurde. Senden Sie sofort eine weitere Anforderung (siehe dazu die Schritte weiter unten), damit die Callback-Funktion aktiv bleibt.
Stoppen von Heavyweight-Callbacks
Senden Sie zum Stoppen einer zuvor erstellten Heavyweight-Callback-Funktion eine GET-Anforderung an den folgenden URL:
http://host:port/datasnap/rest/DSAdmin/CloseClientChannel/[SCN]/[CHID]/[ST]
SCN, CHID und ST sind dabei dieselben Werte, die beim ersten Erstellen übergeben wurden.
Hinzufügen einer Callback-Funktion zu einem Client-Kanal
Ein Client-Kanal kann mehrere verschachtelte Callback-Funktionen enthalten. Es muss aber mindestens eine vorhanden sein. Senden Sie zum Registrieren einer weiteren Callback-Funktion bei dem Client-Kanal den folgenden URL mit einer GET-Anforderung:
http://host:port/datasnap/rest/DSAdmin/RegisterClientCallbackServer/[SCN]/[CHID]/[CBID]/[SCNS]/[ST]/
SCN, CHID, SCNS und ST sind dabei dieselben Werte, die Sie beim Erstellen des Client-Kanals angegeben haben, und CBID ist eine für den Client-Kanal eindeutige ID für die neue Callback-Funktion.
Entfernen einer Callback-Funktion aus einem Client-Kanal
Callbacks können aus einem Client-Kanal entfernt werden. Wenn Sie die letzte Callback-Funktion entfernen, wird der Kanal geschlossen. Senden Sie zum Entfernen einer Callback-Funktion den folgenden URL mit einer GET-Anforderung:
http://host:port/datasnap/rest/DSAdmin/UnregisterClientCallback/[SCN]/[CHID]/[CBID]/[SCNS]/[ST]/
SCN, CHID, SBID, SCNS und ST sind dabei dieselben Werte, die Sie beim Registrieren der Callback-Funktion (entweder mit der ConsumeClientChannel- oder der RegisterClientCallbackServer-Methode) übergeben haben.
Antworten vom Server
Eine Antwort auf eine Heavyweight-Callback-Anforderung kann in verschiedenen Situationen auftreten. Wie bereits weiter oben erwähnt, erfolgt eine, wenn der Kanal erfolgreich erstellt wurde. Eine weitere, wenn die Heavyweight-Callback-Funktion geschlossen wird. Die häufigste Antwort ist jedoch ein Broadcast oder eine Nachricht. Nachrichten von einem Server zielen auf eine einzelne Callback-Funktion eines Client-Kanals ab, während Broadcasts an alle Callbacks ausgegeben werden sollten.
Bei einer Callback-Funktion mit der ID "cd12345" könnte ein Antworttext einer gesendeten Anforderung folgendermaßen aussehen:
{"result":[{"invoke":["cb12345","Hello World" ,1]}]}
Dieser Antworttext bedeutet, dass ein Aufruf (Nachricht) vom Server mit dem Inhalt gesendet wurde, dass die Callback-Funktion mit der ID "cd12345" aufgerufen und der String-Wert "Hello World" vom Typ 1 übergeben werden soll. Typ 1 bedeutet, dass der Wert als JSON behandelt werden soll. Typ 2 bedeutet, dass er eine JSON-Objektrepräsentation eines Benutzerobjekts ist. Typ 1 ist vermutlich gebräuchlicher. Der Wert muss kein String sein, er kann ein beliebiger JSON-Wert sein.
Sendet der Server einen Broadcast, dann wird er an alle Callbacks des Client-Kanals gerichtet und enthält daher keine ID. Der Antworttext würde folgendermaßen lauten:
{"result":[{"broadcast":["Hello World",1]}]}
Wird die Heavyweight-Callback-Funktion geschlossen, wird der folgende Antworttext zurückgegeben:
{"result":[{"close":true}]}
Beantworten einer Antwort vom Server
Wenn die Heavyweight-Callback-Anforderung eine Antwort vom Server erhält, müssen Sie die Botschaft so schnell wie möglich behandeln und dann eine neue Anforderung ausführen. Die Anforderung, die Sie senden, ist fast identisch mit der Anforderung zum Registrieren des Client-Kanals, mit nur einigen kleinen Unterschieden. Erstens muss der Befehl als POST gesendet werden. Der URL der Anforderung würde folgendermaßen aussehen:
http://host:port/datasnap/rest/DSAdmin/ConsumeClientChannel/[SCN]/[CHID]//[ST]
CBID ist ein leerer String (weil keine neuen Callbacks registriert werden) und weil es sich um ein POST handelt, wird der letzte Parameter (ein leerer String; zwei Schrägstriche für die Registrierung des Client-Kanals) weggelassen. Dieser wird im Anforderungsrumpf übergeben.
Der Anforderungsrumpf muss das vom Client-Kanal zurückgegebene Ergebnis (das ein JSON-Wert im String-Format sein kann) enthalten. Im Allgemeinen hat es sich bewährt entweder "True" oder "False" zurückzugeben. Wenn die Benachrichtigung ausgeführt wurde, sollte das Ergebnis der Wert sein, der für die spezifische, aufzurufende Callback-Funktion zurückgegeben wurde. Wenn der Broadcast ausgeführt wurde, sollte der zurückgegebene Wert auf allen von den Callbacks gelieferten Werten basieren (z.B. "False" außer alle Callbacks haben "True" zurückgegeben).
Weitere Informationen finden Sie unter Codeintensive REST-Callback-Funktionen.
Ein Beispiel für Übertragungen mit PHP DataSnap REST
Das folgende native PHP-Codebeispiel verwendet DataSnap REST für die Übergabe eines Arrays.
<?php
// type -> unit name (uCidade) . object name (TCidade)
// fileds -> fields must be the same in declared class
$cidade = array( "type" => "uCidade.TCidade" , "id" => 1 , "fields" => array ( "FId" => 41000 , "FDescricao" => "LINS" , "FUF" => "SP" ) );
$url = 'http://localhost:8080/datasnap/rest/TServerMethodsMain/%22AddCidade%22/' ;
$ch = curl_init() ;
curl_setopt( $ch , CURLOPT_HTTPHEADER, array ( "Accept: application/json" , "Content-Type: text/xml; charset=utf-8" ) ) ;
curl_setopt( $ch , CURLOPT_HEADER , FALSE ) ;
curl_setopt( $ch , CURLOPT_RETURNTRANSFER , true ) ;
curl_setopt( $ch , CURLOPT_POST , TRUE ) ;
curl_setopt( $ch , CURLOPT_URL , $url ) ;
curl_setopt( $ch , CURLOPT_POSTFIELDS , json_encode( $cidade ) ) ;
$result = curl_exec( $ch ) ;
echo '<pre>';
print_r ($result);
echo '</pre>';
?>
Hinweis: RAD PHP hat einen eigenen Proxy-Generator, es generiert aber kein TJSONObject, wie aus dem obigen Beispiel ersichtlich.