REST vs JSON-RPC?

J’essaie de choisir entre REST et JSON-RPC pour développer une API pour une application Web. Lequel est plus facile à utiliser pour les clients API?

Mise à jour 2015: J’ai trouvé REST plus facile à développer et à utiliser pour une API servie sur Web / HTTP, car l’API permet d’exploiter le protocole HTTP existant et mature, compris à la fois par le client et par le serveur. Par exemple, les codes de réponse, les en-têtes, les requêtes, les corps de message, la mise en cache et de nombreuses autres fonctionnalités peuvent être utilisés par l’API sans effort ni configuration supplémentaire.

Le problème fondamental avec RPC est le couplage. Les clients RPC sont étroitement liés à l’implémentation du service de plusieurs manières et il devient très difficile de modifier l’implémentation du service sans casser les clients:

  • Les clients doivent connaître les noms des procédures.
  • Les parameters de procédure d’ordre, les types et le nombre comptent. Il n’est pas facile de modifier les signatures de procédure (nombre d’arguments, ordre des arguments, types d’arguments, etc.) côté serveur sans casser les implémentations des clients.
  • Le style RPC n’expose que des points de terminaison de procédure + des arguments de procédure. Il est impossible pour le client de déterminer ce qui peut être fait ensuite.

D’autre part, dans le style REST, il est très facile de guider les clients en incluant des informations de contrôle dans les représentations (en-têtes HTTP + représentation). Par exemple:

  • Il est possible (et en fait obligatoire) d’incorporer des liens annotés avec des types de relation de lien qui véhiculent des significations de ces URI;
  • Les implémentations client n’ont pas besoin de dépendre de noms de procédures et d’arguments particuliers. Au lieu de cela, les clients dépendent des formats de message. Cela crée la possibilité d’utiliser des bibliothèques déjà implémentées pour des formats de média particuliers (par exemple, Atom, HTML, Collection + JSON, HAL etc …)
  • Il est possible de modifier facilement les URI sans casser les clients, dans la mesure où ils ne dépendent que de relations de liens enregistrées (ou spécifiques à un domaine);
  • Il est possible d’incorporer des structures de type formulaire dans les représentations, en donnant aux clients la possibilité d’exposer ces descriptions en tant que fonctionnalités d’interface utilisateur si l’utilisateur final est humain.
  • La prise en charge de la mise en cache est un avantage supplémentaire.
  • Codes d’état normalisés;

Il y a beaucoup plus de différences et d’avantages du côté REST.

J’ai exploré le problème en détail et j’ai décidé que le REST pur est bien trop contraignant, et que RPC est le meilleur, même si la plupart de mes applications sont des applications CRUD. Si vous vous en tenez à REST, vous finirez par vous demander comment vous pouvez facilement append une autre méthode nécessaire à votre API dans un but particulier. Dans de nombreux cas, la seule façon de procéder avec REST consiste à créer un autre contrôleur, ce qui peut compliquer indûment votre programme.

Si vous choisissez RPC, la seule différence est que vous spécifiez explicitement le verbe dans le cadre de l’URI, ce qui est clair, cohérent, moins bogué et sans aucun problème. Surtout si vous créez une application qui va bien au-delà du simple CRUD, RPC est la seule solution. J’ai un autre problème avec les puristes RESTful: HTTP POST, GET, PUT, DELETE ont des significations précises dans HTTP qui ont été subverties par REST en d’autres choses, simplement parce qu’elles s’adaptent la plupart du temps – mais pas tout le temps.

En programmation, j’ai depuis longtemps trouvé que le fait d’essayer d’utiliser une chose pour signifier deux choses allait arriver quelque temps et vous mordre. J’aime avoir la possibilité d’utiliser POST pour à peu près toutes les actions, car il offre la liberté d’envoyer et de recevoir des données selon vos besoins. Vous ne pouvez pas intégrer le monde entier dans CRUD.

Premièrement, HTTP-REST est une architecture de “transfert de représentation”. Cela implique beaucoup de choses intéressantes:

  • Votre API sera sans état et donc beaucoup plus facile à concevoir (il est vraiment facile d’oublier une transition dans un automate complexe), et de l’intégrer à des composants logiciels indépendants.
  • Vous serez amené à concevoir des méthodes de lecture sûres , faciles à mettre en cache et à intégrer.
  • Vous serez amené à concevoir des méthodes d’écriture en tant que méthodes idempotentes , qui traiteront beaucoup mieux les délais d’attente.

Deuxièmement, HTTP-REST est entièrement compatible avec HTTP (voir “safe” et “idempotent” dans la partie précédente), vous pourrez donc réutiliser les bibliothèques HTTP (existantes pour tous les langages existants) et les reverse proxy HTTP, ce qui vous donnera la possibilité d’implémenter des fonctionnalités avancées (cache, authentification, compression, redirection, réécriture, journalisation, etc.) avec une ligne de code nulle.

Last but not least, utiliser HTTP comme protocole RPC est une erreur énorme selon le concepteur de HTTP 1.1 (et inventeur de REST): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

De bonnes réponses – je voulais juste clarifier certains des commentaires. JSON-RPC est rapide et facile à utiliser, mais les ressources et les parameters mentionnés sont étroitement liés et ont tendance à dépendre de verbes (api / deleteUser, api / addUser) utilisant GET / POST où REST fournit des ressources faiblement couplées (api / utilisateurs) que dans une API HTTP REST repose sur plusieurs méthodes HTTP (GET, POST, PUT, PATCH, DELETE). REST est un peu plus difficile à mettre en œuvre pour les développeurs inexpérimentés, mais le style est devenu assez courant et offre beaucoup plus de flexibilité à long terme (donnant à votre API une plus longue durée de vie).

En plus de ne pas avoir de ressources étroitement couplées, REST vous permet également d’éviter de vous engager dans un seul type de contenu. Cela signifie que si votre client a besoin de recevoir les données en XML, JSON ou même YAML. renvoyer ceux qui utilisent les en-têtes content-type / accept.

Cela vous permet de garder votre API suffisamment flexible pour prendre en charge de nouveaux types de contenu OU des exigences client.

Mais ce qui sépare véritablement REST de JSON-RPC, c’est qu’il suit une série de contraintes soigneusement étudiées, ce qui garantit une flexibilité architecturale. Ces contraintes consistent notamment à faire en sorte que le client et le serveur puissent évoluer indépendamment les uns des autres (vous pouvez apporter des modifications sans perturber l’application de votre client), les appels sont sans état (l’état est représenté par hypermédia), une interface uniforme est fournie pour les interactions. l’API est développée sur un système en couches et la réponse peut être mise en cache par le client. Il existe également une contrainte facultative pour fournir du code à la demande.

Cependant, avec tout cela, les API MOST ne sont pas RESTful (selon Fielding) car elles n’intègrent pas d’hypermédia (liens hypertextes incorporés dans la réponse qui aident à naviguer dans l’API). La plupart des API que vous découvrirez sont similaires à REST dans la mesure où elles suivent la plupart des concepts de REST, mais ignorent cette contrainte. Cependant, de plus en plus d’API implémentent cela et cela devient de plus en plus une pratique courante.

Cela vous donne également une certaine flexibilité car les API pilotées par hypermédia (telles que Stormpath) dirigent le client vers les URI (ce qui signifie que si quelque chose change, dans certains cas, vous pouvez modifier l’URI sans impact négatif). statique. Avec RPC, vous devrez également documenter de manière approfondie ces différents URI et expliquer comment ils fonctionnent les uns par rapport aux autres.

En général, je dirais que REST est la voie à suivre si vous voulez créer une API extensible et flexible qui durera longtemps. Pour cette raison, je dirais que c’est la voie à suivre 99% du temps.

Bonne chance Mike

Si votre service fonctionne correctement avec uniquement les modèles et le modèle GET / POST / PUT / DELETE, utilisez pure REST.

Je suis d’accord que HTTP est à l’origine conçu pour les applications sans état.

Mais pour les applications temps réel (Web) plus complexes et modernes (!) Où vous souhaiterez utiliser des Websockets (qui impliquent souvent des états), pourquoi ne pas utiliser les deux? JSON-RPC sur Websockets est très léger, vous avez donc les avantages suivants:

  • Mises à jour instantanées sur chaque client (définissez votre propre appel RPC serveur-client pour la mise à jour des modèles)
  • Facile à append à la complexité (essayez de créer un clone Etherpad avec uniquement REST)
  • Si vous le faites correctement (ajoutez le RPC uniquement en tant que supplément pour le temps réel), la plupart sont toujours utilisables avec REST uniquement (sauf si la fonctionnalité principale est une discussion ou quelque chose)

Comme vous ne faites que concevoir l’API côté serveur, commencez par définir les modèles REST, puis ajoutez le support JSON-RPC si nécessaire, en limitant au minimum le nombre d’appels RPC.

(et désolé pour les parenthèses abusent)

L’OMI, l’essentiel est l’orientation vs l’orientation des ressources. REST est orienté ressources et s’adapte bien aux opérations CRUD. Etant donné sa sémantique connue, il fournit une certaine prévisibilité à un premier utilisateur, mais lorsqu’il est implémenté à partir de méthodes ou de procédures, il vous oblige à fournir une traduction artificielle au monde centré sur les ressources. D’autre part, RPC convient parfaitement aux API orientées vers l’action, où vous exposez des services, et non des ensembles de ressources CRUD.

Nul doute que REST est plus populaire, cela ajoute certainement quelques points si vous souhaitez exposer l’API à un tiers.

Si ce n’est pas le cas (par exemple en cas de création d’un frontal AJAX dans un SPA), mon choix est RPC. En particulier JSON-RPC, combiné avec le schéma JSON en tant que langage de description, et transporté via HTTP ou Websockets en fonction du cas d’utilisation.

JSON-RPC est une spécification simple et élégante qui définit les charges utiles JSON de demande et de réponse à utiliser dans RPC synchrone ou asynchrone.

JSON Schema est un brouillon définissant un format basé sur JSON destiné à décrire les données JSON. En décrivant vos messages d’entrée et de sortie de service à l’aide du schéma JSON, vous pouvez avoir une complexité arbitraire dans la structure des messages sans compromettre la facilité d’utilisation, et l’intégration des services peut être automatisée.

Le choix du protocole de transport (HTTP vs Websockets) dépend de différents facteurs, le plus important étant que vous ayez besoin de fonctionnalités HTTP (mise en cache, revalidation, sécurité, idempotence, type de contenu, multi-parties, …) messages à haute fréquence.

Jusqu’à présent, c’est mon opinion personnelle sur la question, mais maintenant, quelque chose de très utile pour les développeurs Java qui lisent ces lignes, le cadre sur lequel j’ai travaillé au cours de l’année dernière, né de la même question que vous vous posez maintenant. :

http://rpc.brutusin.org

Vous pouvez voir une démonstration en direct ici, montrant l’explorateur de référentiel intégré pour les tests fonctionnels (merci JSON Schema) et une série de services d’exemple:

http://demo.rpc.brutusin.org

J’espère que ça aide mon pote!

Nacho

J’ai été un grand fan de REST dans le passé et cela présente de nombreux avantages par rapport au RPC sur papier. Vous pouvez présenter le client avec différents types de contenu, mise en cache, réutilisation des codes d’état HTTP, vous pouvez guider le client via l’API et incorporer de la documentation dans l’API si elle ne s’explique pas de toute façon.

Mais mon expérience a été que dans la pratique, cela ne tient pas la route et que vous faites beaucoup de travail inutile pour tout régler correctement. De plus, les codes d’état HTTP ne correspondent souvent pas exactement à la logique de votre domaine et leur utilisation dans votre contexte est souvent un peu forcée. Mais à mon avis, la pire chose à propos de REST est que vous passez beaucoup de temps à concevoir vos ressources et les interactions qu’elles permettent. Et chaque fois que vous faites des ajouts majeurs à votre API, vous espérez trouver une bonne solution pour append la nouvelle fonctionnalité et vous ne vous êtes pas déjà créé un coin.

Cela me semble souvent une perte de temps, car la plupart du temps, j’ai déjà une idée parfaitement précise de la modélisation d’une API en tant qu’ensemble d’appels de procédure distants. Et si je suis passé par tous ces efforts pour modéliser mon problème dans les contraintes de REST, le problème suivant est de savoir comment l’appeler du client? Nos programmes sont basés sur des procédures d’appel afin de créer facilement une bibliothèque client RPC, en construisant une bonne bibliothèque client REST pas beaucoup et, dans la plupart des cas, vous ne faites que revenir de votre API REST sur le serveur à un ensemble de procédures de votre client. bibliothèque.

Pour cette raison, RPC se sent beaucoup plus simple et naturel pour moi aujourd’hui. Ce qui me manque vraiment, c’est un framework cohérent qui facilite l’écriture de services RPC auto-descriptifs et interopérables. Par conséquent, j’ai créé mon propre projet pour expérimenter de nouvelles façons de simplifier RPC et peut-être que quelqu’un d’autre le trouve utile également: https://github.com/aheck/reflectrpc

Selon le modèle de maturité de Richardson , la question n’est pas REST vs RPC , mais combien de REST ?

Dans cette vue, la conformité à la norme REST peut être classée en 4 niveaux.

  • niveau 0: penser en termes d’actions et de parameters. Comme l’explique l’article, ceci est essentiellement équivalent à JSON-RPC (l’article l’explique pour XML-RPC, mais les mêmes arguments sont valables pour les deux).
  • niveau 1: penser en termes de ressources. Tout ce qui concerne une ressource appartient à la même URL
  • niveau 2: utiliser les verbes HTTP
  • niveau 3: HATEOAS

Selon le créateur de la norme REST, seuls les services de niveau 3 peuvent être appelés RESTful. Cependant, il s’agit d’une mesure de la conformité et non de la qualité. Si vous voulez simplement appeler une fonction distante qui effectue un calcul, cela n’a probablement aucun sens d’avoir des liens hypermédias pertinents dans la réponse, ni de différenciation du comportement basé sur le verbe HTTP utilisé. Ainsi, un tel appel a tendance à être plus semblable à RPC. Cependant, un niveau de conformité inférieur ne signifie pas nécessairement un état ou un couplage plus élevé. Probablement, au lieu de penser à REST vs RPC , vous devriez utiliser autant de REST que possible, mais pas plus. Ne tordez pas votre application pour l’adapter aux normes de conformité RESTful.

Pourquoi JSON RPC:

En cas de REST apis, nous devons définir un contrôleur pour chaque fonctionnalité / méthode dont nous pourrions avoir besoin. Par conséquent, si nous voulons que 10 méthodes soient accessibles à un client, nous devons écrire 10 contrôleurs pour connecter la demande du client à une méthode particulière.

Un autre facteur est que, même si nous avons des contrôleurs différents pour chaque méthode / fonctionnalité, le client doit se rappeler d’utiliser POST ou GET. Cela complique les choses. En plus de cela pour envoyer des données, il faut définir le type de contenu de la demande si POST est utilisé.

Dans le cas de RPC JSON, les choses sont grandement simplifiées car la plupart des serveurs JSONRPC fonctionnent sur les méthodes HTTP POST et le type de contenu est toujours application / json. Cela évite de devoir utiliser les parameters HTTP et de méthode HTTP appropriés du côté client.

Il n’est pas nécessaire de créer des contrôleurs distincts pour les différentes méthodes / fonctionnalités que le serveur souhaite exposer à un client.

Pourquoi REST:

Vous avez des URL distinctes pour différentes fonctionnalités que le serveur souhaite exposer au côté client. Par conséquent, vous pouvez intégrer ces URL.

La plupart de ces points sont discutables et dépendent entièrement du besoin d’une personne.

Mauvaise question: impose un manichéen qui n’existe pas!

Vous pouvez utiliser JSON-RPC avec “less verb” (aucune méthode ) et conserver la standardisation minimale nécessaire pour les identifiants sendo, les parameters, les codes d’ erreur et les messages d’ avertissement . Le standard JSON-RPC ne dit pas “vous ne pouvez pas être REST”, mais seulement comment emballer les informations de base.

“REST JSON-RPC” existe ! est REST avec les “meilleures pratiques”, pour un emballage minimal de l’information, avec des contrats simples et solides.


Exemple

(de cette réponse et contexte didactique)

Lorsque vous traitez avec REST, il est généralement utile de commencer par penser en termes de ressources. Dans ce cas, la ressource n’est pas simplement un “compte bancaire” mais une transaction de ce compte bancaire … Mais JSON-RPC n’oblige pas le paramètre “method”, tous sont encodés par “path” du noeud final.

  • Dépôt REST avec POST /Bank/Account/John/Transaction avec demande JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}} .
    La réponse JSON peut être quelque chose comme {"jsonrpc": "2.0", "result": "sucess", "id": 12}

  • REST Retirer avec POST /Bank/Account/John/Transaction … similaire.

  • GET /Bank/Account/John/Transaction/12345@13 … Cela pourrait renvoyer un enregistrement JSON de cette transaction exacte (par exemple, vos utilisateurs veulent généralement un enregistrement des débits et des crédits sur leur compte). Quelque chose comme {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13} . La requête GET relative à la convention (REST) ​​peut inclure l’encodage de l’identifiant par “@id”, il n’est donc pas nécessaire d’envoyer de JSON, mais d’utiliser toujours JSON-RPC dans le pack de réponses.

REST est étroitement lié à HTTP, donc si vous n’exposez que votre API via HTTP, REST convient mieux à la plupart des situations (mais pas à toutes). Cependant, si vous devez exposer votre API sur d’autres transports tels que la messagerie ou les sockets Web, REST n’est tout simplement pas applicable.

Si vous demandez des ressources, l’API RESTful est mieux conçue. Si vous demandez des données compliquées avec beaucoup de parameters et des méthodes compliquées autres que le simple CRUD, alors RPC est la bonne solution.

Je pense, comme toujours, ça dépend …

REST a l’énorme avantage d’un soutien public généralisé et cela signifie beaucoup d’outils et de livres. Si vous avez besoin de créer une API utilisée par un grand nombre de consommateurs d’organisations différentes, c’est la solution pour une seule raison: elle est populaire. En tant que protocole, il s’agit bien sûr d’un échec total, car il existe trop de façons complètement différentes de mapper une commande à une URL / verbe / réponse.

Par conséquent, lorsque vous écrivez une application Web à page unique qui doit communiquer avec un moteur, je pense que REST est beaucoup trop complexe. Dans cette situation, vous n’avez pas à vous soucier de la compatibilité à long terme, car l’application et l’API peuvent évoluer ensemble.

Une fois, j’ai commencé avec REST pour une application Web d’une seule page, mais les commandes fines entre l’application Web et le serveur m’ont rapidement rendu fou. Dois-je l’encoder comme paramètre de chemin? Dans le corps? Un paramètre de requête? Un en-tête? Après le design URL / Verb / Response, j’ai ensuite dû coder ce bogue dans Javascript, le décodeur de Java, puis appeler la méthode actuelle. Bien qu’il existe de nombreux outils, il est vraiment difficile de ne pas avoir de sémantique HTTP dans votre code de domaine, ce qui est vraiment une mauvaise pratique. (Cohésion)

Essayez de créer un fichier Swagger / OpenAPI pour un site de taille moyenne et comparez-le à une interface Java unique décrivant les procédures distantes de ce fichier. L’augmentation de la complexité est stupéfiante.

Je suis donc passé de REST à JSON-RPC pour l’application Web à page unique. aI a développé une minuscule bibliothèque qui encodait une interface Java sur le serveur et l’envoyait au navigateur. Dans le navigateur, cela a créé un proxy pour le code de l’application qui a renvoyé une promesse pour chaque fonction.

Encore une fois, REST a sa place juste parce qu’il est célèbre et donc bien supporté. Il est également important de reconnaître la philosophie sous-jacente des ressources sans état et le modèle hiérarchique. Cependant, ces principes peuvent tout aussi facilement être utilisés dans un modèle RPC. JSON RPC fonctionne sur HTTP et présente donc les mêmes avantages que REST dans ce domaine. La différence est que lorsque vous rencontrez inévitablement ces fonctions qui ne correspondent pas bien à ces principes, vous n’êtes pas obligé de faire beaucoup de travail inutile.

Je pense qu’il y a un point que les gens ont oublié de mentionner. Si vous avez déjà une application Web, alors REST est souhaitable car vous aurez de toute façon besoin du serveur d’application et vous pourrez sécuriser les deux en utilisant https … mais si vous ne possédez pas d’application Web, vous devez avoir une application. est souhaitable car vous n’avez plus besoin de configurer un serveur d’applications et de le configurer, ce qui est une hâte. En dehors de cela, je ne vois aucun avantage fondamental dans les deux.

Il serait préférable de choisir JSON-RPC entre REST et JSON-RPC pour développer une API pour une application Web plus facile à comprendre. JSON-RPC est préférable car son mappage aux appels de méthode et aux communications peut être facilement compris.

Choisir l’approche la plus appropriée dépend des contraintes ou de l’objective principal. Par exemple, dans la mesure où la performance est un trait majeur, il est conseillé de choisir JSON-RPC (par exemple, High Performance Computing). Toutefois, si l’objective principal est d’être agnostique afin d’offrir une interface générique à inférer par d’autres, il est conseillé d’utiliser REST. Si les deux objectives doivent être atteints, il est conseillé d’inclure les deux protocoles.

Le fait qui divise en réalité REST de JSON-RPC est qu’il suit une série de contraintes soigneusement étudiées, confirmant la flexibilité architecturale. Les contraintes sont de veiller à ce que le client et le serveur puissent évoluer indépendamment les uns des autres (des modifications peuvent être apscopes sans perturber l’application du client), les appels sont sans état (l’état est considéré comme hypermédia), un l’interface est offerte pour les interactions, l’API est avancée sur un système en couches (Hall, 2010). JSON-RPC est rapide et facile à consumr, cependant que les ressources mentionnées ainsi que les parameters sont étroitement liés et dépendront probablement de verbes (api / addUser, api / deleteUser) utilisant GET / POST alors que REST fournit des ressources faiblement couplées (api / users) dans un HTTP. L’API REST dépend de plusieurs méthodes HTTP telles que GET, PUT, POST, DELETE, PATCH. REST est légèrement plus difficile à mettre en œuvre pour les développeurs inexpérimentés.

JSON (noté comme object JavaScript) étant un format d’échange de données léger, il est facile à lire et à écrire pour les humains. Il est sans tracas pour les machines à parsingr et à générer. JSON est un format de texte qui est entièrement indépendant du langage mais pratique des conventions connues des programmeurs de la famille des langages, comprenant C #, C, C ++, Java, Perl, JavaScript, Python et de nombreux autres. Ces propriétés font de JSON un langage d’échange de données parfait et un choix plus judicieux.

J’utilise vdata pour le protocole RPC: http://vdata.dekuan.org/

1, PHP et JavaScript sont tous deux acceptables. 2, l’appel de partage de ressources d’origine croisée (CORS) est toujours correct.