Die richtige JSON-API oder JSON-RPC

Was ist die JSON-API?

Sicher wissen viele Bescheid.

JSON - Textformat für den JSON- Datenaustausch
API - API- Anwendungsprogrammierschnittstelle

Schlüsselwörter hier: Datenaustauschschnittstelle.

A, was ist dann JSON-RPC?

JSON - wir wissen es bereits.

RPC - Remoteprozeduraufruf RPC

Wir schließen daraus, dass JSON-RPC: Remote-Datenaustausch ist.

Sicherlich wird dieser Datenaustausch mit einer bestimmten Schnittstelle stattfinden, d.h. mit der API.

Und was ist das Problem ?! Du fragst. Tatsache ist, dass einige Programmierer, die die JSON-API entwickeln, d. H. Die Schnittstelle, JSON-RPC vergessen. Und die nächste Erfindung des Fahrrads beginnt. Der Frontend-Programmierer sagt: "Ich werde Ihnen einen solchen Json geben", und der Backend-Programmierer antwortet: "Ich werde Ihnen einen solchen Json zurückgeben". Und alles wäre in Ordnung, aber es wäre gut, sich daran zu erinnern, dass intelligente Menschen seit langem Standards oder vielmehr Datenaustauschprotokolle entwickelt haben. Und nicht einige super komplexe, sondern sehr einfache: JSON-RPC

Höchstwahrscheinlich, wenn nicht zu sagen, dass fast jeder diese Protokolle kennt und sogar verwendet. Eine Reihe von Servern werden geschrieben usw. Aber persönlich hat mir in den bestehenden Protokollen nicht alles gepasst. Sie schienen mir nicht flexibel genug und nicht in allem logisch. Wie Sie vielleicht erraten haben, habe ich beschlossen, mein Fahrrad json-rpc-1.5 zu erfinden

Die Hauptunterschiede zu bestehenden Protokollen sind:

• Optionaler Vorzeichenparameter - Signatur oder Token
• In Abfragen wird anstelle des Parameters param der Datenparameter verwendet, weil Wir senden immer Daten, nicht nur Parameter.
• In allen Antworten wird immer der Parameter "Ergebnis" zurückgegeben, der eine Beschreibung des Ergebnisses der Abfrage "Erfolg" oder "Fehler" enthält.
• Alle Daten in den Antworten sind im Parameter "Daten" enthalten
• Sie können Aliase verwenden, um die Anforderungs- und Antwortparameter zu benennen.

Es mag scheinen. dass die Unterschiede gering sind, aber sie sind von grundlegender Bedeutung.
Übrigens erschien dieses Protokoll in der Praxis, d.h. Beim Erstellen der JSON-API habe ich den in diesem Protokoll beschriebenen Ansatz verwendet.

PS:

Nachdem ich eine Reihe negativer Kommentare und Minuspunkte erhalten hatte, beschloss ich erneut zu prüfen, ob ich wirklich etwas falsch mache. Natürlich schreibe ich hier nur meine persönliche Meinung und lege niemandem etwas auf. Lassen Sie mich einige Beispiele nennen:
1. Beispiel für eine direkte JSON-API- Anforderung von Yandex :

{ "method": "GetClientInfo", "param": ["agrom"], "locale": "ru", "token": "0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f" } 

Sie können auch über Token lesen: Autorisierungstoken

2. Beispiel aus der Sberbank API Zahlung aus einer mobilen Anwendung mit Apple Pay
Ich werde keine JSON-Anfrage stellen, es ist groß, Sie können den Link sehen.
Es ist wichtig, dass die JSON-Anforderung ein "Zahlungstoken" enthält. Hier ist ein Link zu den Token Formation-Anforderungen von Apple

Es ist wichtig zu verstehen, dass Token und Signaturen in der API häufig verwendet werden, natürlich zusammen mit anderen Schutzmethoden. Und diejenigen, die mit verschiedenen APIs arbeiten, wissen das sehr gut.