La bonne API JSON ou JSON RPC

Qu'est-ce que l'API JSON?

Certes, beaucoup de gens savent.

JSON - Format texte pour l'échange de données JSON
API - Interface de programmation d'application API

Mots-clés ici: interface d'échange de données.

A, alors qu'est-ce que JSON-RPC?

JSON - nous sommes déjà au courant.

RPC - appel de procédure distante RPC

Nous concluons que JSON-RPC est: échange de données à distance.

Cet échange de données se produira sûrement avec une certaine interface, c'est-à-dire avec l'API.

Et quel est le problème?! Vous demandez. Et le fait est que certains programmeurs développant l'API JSON, c'est-à-dire l'interface, oublient JSON-RPC. Et la prochaine invention du vélo commence. Le programmeur Frontend dit: "Je vous donnerai un tel json", et le programmeur Backend répond: "Je vous rendrai un tel json". Et tout irait bien, mais il serait bon de se rappeler que les gens intelligents ont développé depuis longtemps des normes, ou plutôt des protocoles d'échange de données. Et pas des super complexes, mais très simples: JSON-RPC

Très probablement, sinon pour dire que presque tout le monde connaît et utilise même ces protocoles. Un tas de serveurs sont écrits, etc. Mais personnellement, tout ne me convenait pas dans les protocoles existants. Ils me semblaient pas assez flexibles et pas logiques en tout. Comme vous l'aurez deviné, j'ai décidé d'inventer mon vélo json-rpc-1.5

Les principales différences par rapport aux protocoles existants sont:

• Paramètre «signe» facultatif - Signature ou jeton
• Dans les requêtes, au lieu du paramètre param, le paramètre data est utilisé, car nous envoyons toujours des données, pas seulement des paramètres.
• Dans toutes les réponses, le paramètre «résultat» est toujours renvoyé et il contient une description du résultat de la requête «succès» ou «erreur».
• Toutes les données dans les réponses viennent dans le paramètre «données»
• Vous pouvez utiliser des alias pour nommer les paramètres de demande et de réponse.

Cela peut sembler. que les différences sont mineures, mais elles sont fondamentalement importantes.
Soit dit en passant, ce protocole est apparu dans la pratique, c'est-à-dire Lors de la création de json api, j'ai utilisé l'approche décrite dans ce protocole.

PS:

Ayant reçu un tas de commentaires négatifs et d'inconvénients, j'ai décidé de vérifier à nouveau, peut-être que je fais vraiment quelque chose de mal? Naturellement, tout ce que j'écris ici est mon opinion personnelle et je n'impose rien à personne. Permettez-moi de vous donner quelques exemples:
1. Exemple de requête API JSON directe Yandex :

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

Ils peuvent également lire sur les jetons: jetons d'autorisation

2. Exemple de paiement Sberbank API à partir d'une application mobile utilisant Apple Pay
Je ne donnerai pas de demande JSON, c'est grand, vous pouvez voir le lien.
Il est important que la demande JSON contienne un «paymentToken». Voici un lien vers les exigences de formation des jetons d'Apple

Il est important de comprendre que les jetons et les signatures dans l'API sont souvent utilisés, naturellement avec d'autres méthodes de protection. Et ceux qui travaillent avec diverses API le savent très bien.