JSON-RPC

• standardisiertes Interface
• asynchron, funktioniert mit IDs
• zum Aufruf von Methoden auf entfernten Maschinen
• gut zu nutzen in WWW-Umgebungen
• ver 1.0 (von 2005) läuft peer-to-peer
• ver 2.0 (von 2010) läuft client-server

Googles APIs benutzten bis 12. August 2019 noch JSON-RPCs. Dann wurde umgeschaltet auf REST. Oh, die guten Gaben von oben!

edu.pieli.net meint, dass aufgrund der Einfachheit des Interfaces bei gleichzeitiger Schachtelbarkeit am schnellsten sehr komplexe Ergebnisse erzielt werden können. Das skaliert also bestens.

Anfragetypen

• mit {JSON-Objekt}
• Aufteilung in
  • Requests -> Server soll eine Antwort liefern
  • Notification -> Einwegkommunikation, Antwort vom Server wird nicht erwartet
  • Batch Request -> Mehrere Anfragen (Notifications oder Requests) werden als Array (JSON!) gebündelt an den Server gestellt (ab ver 2.0)

JSON-RPC Request besteht aus

1. jsonrpc – String mit Version (zB "2.0")

2. method – ein String mit dem Namen der angefragten serverseitigen Methode

3. params – Ein Array oder Objekt mit Argumenten für die Methode, die angefragt wird

4. id – Ein eindeutiger Identifikator, der das Bearbeiten/die Zuordnung der (asynchronen) Server-Antwort ermöglicht.

Sonderfall Notification

• ver 1.0: id ist null
• ver 2.0: id fehlt

JSON-RPC-Antwort besteht aus

1. jsonrpc – String mit Version (zB "2.0")

2. result – Rückgabe-Objekt, falls bei der Ausführung der Methode auf dem Server kein Fehler aufgetreten ist. Bei Fehlern lässt ver 2.0 dieses Feld weg, bei ver 1.0 ist es null

3. error – Falls bei der Ausführung der Methode auf dem Server kein Fehler aufgetreten ist, der Fehler-Rückgabewert der Server-Methode. Falls kein Fehler auftrat, lässt ver 2.0 dieses Feld weg, bei ver 1.0 ist es null

4. id – wiederholt das id-Feld des Reuqests, dass der Client diese Antwort zuordnen kann

Bei Notifications entfällt diese Antwort.

Es ist Aufgabe des Clients zB bei ver 2.0, herauszufinden:

Antwort enthält error-Feld -> Die Anfrage ist auf dem Server fehlgeschlagen, nähere Beschreibung des Fehlers in diesem Error-Feld

Anwtort enthält result-Feld -> Es hat alles geklappt, Ergebnisse der angefragten Methode stehen hier.

Beispiel JSON-RPC ver 2.0

JSON-RPC-Request

{
  "id": "tM",
  "jsonrpc": "2.0",
  "method": "tolleMethode",
  "params": ["param1", "param2"]
}

JSON-RPC-Response

{
  "id": "tM",
  "jsonrpc": "2.0",
  "result": "Ergebnisse von tolleMethode"
}

Beispiel JSON-RPC ver 1.0

JSON-RPC-Request

{
 "id": "tM",
 "method": "tolleMethode",
 "params": ["param1", "param2"]
}

JSON-RPC-Response

{
 "id": "tM",
 "error": null,
 "result": "Ergebnisse von tolleMethode"
}

JSON-RPC-Conclutio

Weil das Interface relativ starr ist, lässt es sich Server-seitig relativ einfach implementieren.

Aufgrund der starren Natur (method, params-Array) ist jederzeit klar, was wie übergeben werden muss. Das Interface bleibt also – selbst im Batch-Mode – unterkomplex.

Es eignet sich so gut zum Steuern und kann zB alleine über HTTP-GET betrieben werden.

Der Kanon sagt, dass komplexe Parameter standardmäßig in base64 codiert werden sollen, was die Handhabung weiter erleichtert.

Es handelt sich hierbei also um ein klares, einfaches Interface.

andere Interfaces

• RPC-Einstieg
• SOAP
• REST