2.2.2. JSON-RPC

JSON-RPC ist ebenfalls ein Standardprotokoll. Die Basis für dieses Protokoll sind Objekte, wie sie von JavaScript serialisiert und deserialisiert werden. Neben Javascript, welches dieses Protokoll nativ unterstützt (Stichwort Web 2.0), gibt es für viele Programmier- und Scriptingsprachen entsprechende Erweiterungen. Im Gegensatz zu XML-RPC ist JSON-RPC, was die Menge der übertragenen Daten angeht, etwas platzsparender. Die Meta- bzw. Beschreibungsdaten werden zwar auch übertragen, allerdings für jeden Wert nur einmal (und nicht wie bei XML-RPC für das Start- und End-Tag). Mit diesem Protokoll wird es zum Beispiel möglich, einen Web-Client für beliebige Webbrowser zu schreiben, die keine weitere Zwischenschicht auf einem Webserver benötigen. Der GREYHOUND Server kann direkt vom Client-PC des jeweiligen Anwenders aus dem Webbrowser heraus angesprochen werden. JSON-RPC wird per HTTP bzw. HTTPS über den GREYHOUND Server abgewickelt. Es funktioniert deshalb in aller Regel auch bei sehr restriktiv eingestellten Unternehmensfirewalls. JSON-RPC bedeutet JavaScript Object Notation Remote Procedure Call.
JSON-RPC folgt, was die Analogie zwischen Dokumentation und Request bzw. Response angeht, denselben Regeln wie XML-RPC. GREYHOUND unterstützt JSON in Version 1.1, weil dies der kleinste gemeinsame Nenner ist. JSON-RPC wird per POST an den Server übermittelt. Nun aber zunächst der grundlegende Aufbau von JSON-RPC: Die Daten werden in JSON kompakter zusammengefasst. Hier ein Beispiel einer Variable vom Datentyp Integer:
Quelltext-Beispiel:
1
{"MyVar": 34}
Wie man sieht wird der Datentyp in der Anfrage nicht übermittelt. Das liegt daran, dass JavaScript zunächst typenlos ist. Durch den Wert der Variable ergibt sich der Datentyp automatisch. Im Gegensatz zu XML-RPC wird der Name der Variable in JSON immer übermittelt.
Es folgt das Beispiel der Anfrage für die Methode RpcInfo.GetServerSettings:
Quelltext-Beispiel:
1
2
3
4
5
6
7
8
POST /json HTTP/1.0
User-Agent: MyTestClient
Host: 123.234.123.234
Authorization: Basic ZTRkOTA5YzI5MGQwZmIxY2EwNjhmZmFkZGYyMmNiZDAtb2c6bXlHUkVZSE9VTkRwYXNzd29yZA==
Content-Type: application/json
Content-length: 96

{"version":"1.1", "method": "RpcInfo.GetServerSettings", "params": ["My Value of ExampleParam"]}
Die Parameter werden als Array angegeben. Weitere Parameter würden kommagetrennt angegeben. Die verschiedenen Datentypen können gemischt werden. Das Authorization-Header Feld wird genauso wie beim XML-RPC Protokoll gebildet. Die meisten JSON-RPC Implementation können dies bei Angabe des gewünschten Benutzernamens und Passworts aber ohnehin automatisch. Die Antwort für den Aufruf könnte folgendermaßen lauten:
Quelltext-Beispiel:
1
2
3
4
5
6
7
8
9
10
HTTP/1.1 200 OK
Connection: close
Content-Length: 255
Content-Type: application/json
Date: Fri, 09 Oct 2009 08:00:00 GMT
Server: GREYHOUND RPC Server

{"version":"1.1", "result": {"PhoneAddressItemCountryPrefix": "+49", "ElementsPerPage": 100,
"ElementsPerList": 100, "EventsPerPage": 100, "EventsPerDay": 1000, "MaxSearchResults": 10000,
"DefaultEditorFontName": "Tahoma", "DefaultEditorFontSize": 2}}
Ein Fehler in der JSON-RPC Anfrage würde so beantwortet (in diesem Fall ohne HTTP-Header):
Quelltext-Beispiel:
1
{"version":"1.1","error":{"name":"Exception","code":561,"message":"This is a sample error"}}
Genau wie XML-RPC empfiehlt sich für die Fehlersuche eine Zwischenspeicherung der jeweiligen JSON-RPC Anfragen und Antworten.
Unterthemen
2.2.2.1. Download-Handler
2.2.2.2. Upload-Handler
Themen dieser Ebene
2.2.1. XML-RPC
2.2.2. JSON-RPC