REST vs JSON-RPC? [fermé]

J'essaie de choisir entre REST et JSON-RPC pour développer une API pour une application Web. Comment se comparent-ils?

Mise à jour 2015: j'ai trouvé REST plus facile à développer et à utiliser pour une API qui est servie sur le Web / HTTP, car le protocole HTTP existant et mature qui est compris par le client et le serveur peut être exploité par l'API. 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émentaires.

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

• Les clients doivent connaître les noms des procédures;
• L'ordre des paramètres de procédure, les types et le nombre comptent. Ce n'est pas si facile de changer les signatures de procédure (nombre d'arguments, ordre des arguments, types d'argument etc ...) côté serveur sans casser les implémentations client;
• 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.

En revanche, 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 relations de lien qui véhiculent les significations de ces URI;
• Les implémentations client n'ont pas besoin de dépendre de noms et d'arguments de procédure 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 supports 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 des relations de lien enregistrées (ou spécifiques au domaine);
• Il est possible d'incorporer des structures de type formulaire dans les représentations, donnant aux clients la possibilité d'exposer ces descriptions en tant que capacité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 limitatif, et 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 gratter la tête en vous demandant comment vous pouvez facilement ajouter une autre méthode nécessaire à votre API à des fins spéciales. Dans de nombreux cas, la seule façon de le faire avec REST est de créer un autre contrôleur pour cela, ce qui peut indûment compliquer votre programme.

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

En programmation, il y a longtemps que j'ai découvert qu'essayer d'utiliser une chose pour signifier deux choses allait arriver un jour 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 comme votre méthode doit le faire. Vous ne pouvez pas intégrer le monde entier dans CRUD.

Tout d'abord, HTTP-REST est une architecture de "transfert d'état représentatif". 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 avec des parties logicielles indépendantes.
• 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 idempotentes , qui traiteront beaucoup mieux les délais d'attente.

Deuxièmement, HTTP-REST est entièrement compatible avec HTTP (voir «sûr» et «idempotent» dans la partie précédente), vous pourrez donc réutiliser des bibliothèques HTTP (existantes pour chaque langue existante) et des proxys inverses HTTP, ce qui vous donnera la possibilité d'implémenter des fonctionnalités avancées (cache, authentification, compression, redirection, réécriture, journalisation, etc.) avec zéro ligne de code.

Enfin et surtout, l'utilisation de HTTP comme protocole RPC est une énorme erreur 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

Excellentes réponses - je voulais juste clarifier certains des commentaires. JSON-RPC est rapide et facile à consommer, mais comme les ressources et les paramètres mentionnés sont étroitement couplés et il a tendance à s'appuyer sur des verbes (api / deleteUser, api / addUser) en utilisant GET / POST où REST fournit des ressources à couplage lâche (api / utilisateurs) qui, dans une API HTTP REST, s'appuie sur plusieurs méthodes HTTP (GET, POST, PUT, PATCH, DELETE). REST est légèrement plus difficile à implémenter pour les développeurs inexpérimentés, mais le style est devenu assez courant maintenant et il offre beaucoup plus de flexibilité à long terme (ce qui donne à votre API une durée de vie plus longue).

En plus de ne pas avoir de ressources étroitement couplées, REST vous permet également d'éviter d'être engagé dans un seul type de contenu - cela signifie si votre client a besoin de recevoir les données en XML, ou JSON, ou même YAML - s'il est intégré à votre système, vous pourriez 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 les exigences des clients.

Mais ce qui sépare vraiment REST de JSON-RPC, c'est qu'il suit une série de contraintes soigneusement pensées, garantissant une flexibilité architecturale. Ces contraintes incluent la garantie que le client et le serveur peuvent évoluer indépendamment l'un de l'autre (vous pouvez apporter des modifications sans gâcher l'application de votre client), les appels sont sans état (l'état est représenté via 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 dit - la plupart des API ne sont pas RESTful (selon Fielding) car elles n'incorporent pas d'hypermédia (liens hypertextes intégrés dans la réponse qui aident à naviguer dans l'API). La plupart des API que vous découvrirez sont de type 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 de flux principal.

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), où, comme avec les URI RPC, doivent être statique. Avec RPC, vous devrez également documenter en détail 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 souhaitez 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

OMI, le point clé est l'orientation action vs ressources. REST est axé sur les ressources et convient bien aux opérations CRUD et, étant donné sa sémantique connue, offre une certaine prévisibilité au premier utilisateur, mais lorsqu'il est implémenté à partir de méthodes ou de procédures, vous force à fournir une traduction artificielle au monde centré sur les ressources. D'un autre côté, RPC convient parfaitement aux API orientées action, où vous exposez des services, pas 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.

Sinon (par exemple en cas de création d'un frontal AJAX dans un SPA), mon choix est RPC. En particulier JSON-RPC, combiné avec JSON Schema comme langage de description, et transporté via HTTP ou Websockets selon le 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 le RPC synchrone ou asynchrone.

Le schéma JSON est un projet de spécification définissant un format basé sur JSON visant à 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 convivialité 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, étant le plus important si vous avez besoin de fonctionnalités HTTP (mise en cache, revalidation, sécurité, idempotence, type de contenu, multi-parties, ...) ou si votre application a besoin d'échanger messages à haute fréquence.

Jusqu'à présent, c'est mon opinion personnelle sur la question, mais maintenant quelque chose qui peut être vraiment 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émo en direct ici, montrant le navigateur de référentiel intégré pour les tests fonctionnels (merci JSON Schema) et une série d'exemples de services:

http://demo.rpc.brutusin.org

J'espère que ça aide le compagnon!

Nacho

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

Je suis d'accord que HTTP est initialement conçu pour les applications sans état.

Mais pour les applications (Web) en temps réel modernes et plus complexes (!) Où vous voudrez utiliser des Websockets (qui impliquent souvent un état), 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 mettre à jour les modèles)
• Facile à ajouter de la complexité (essayez de faire un clone Etherpad avec seulement REST)
• Si vous le faites correctement (ajoutez RPC uniquement en tant qu'extra en temps réel), la plupart sont toujours utilisables avec uniquement REST (sauf si la fonctionnalité principale est un chat ou quelque chose)

Comme vous ne concevez que l'API côté serveur, commencez par définir les modèles REST et ajoutez plus tard la prise en charge JSON-RPC selon vos besoins, en limitant au minimum le nombre d'appels RPC.

(et désolé pour la surutilisation des parenthèses)

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

Mais mon expérience a été que, dans la pratique, cela ne tient pas le coup et qu'au lieu de cela, vous faites beaucoup de travail inutile pour tout faire 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 le pire à propos de REST à mon avis est que vous passez beaucoup de temps à concevoir vos ressources et les interactions qu'elles permettent. Et chaque fois que vous effectuez des ajouts majeurs à votre API, vous espérez trouver une bonne solution pour ajouter la nouvelle fonctionnalité et vous ne vous êtes pas déjà conçu dans un coin.

Cela me semble souvent être une perte de temps car la plupart du temps, j'ai déjà une idée parfaitement fine et évidente de la façon de modéliser une API comme un ensemble d'appels de procédure à distance. Et si j'ai traversé tous ces efforts pour modéliser mon problème à l'intérieur des contraintes de REST, le problème suivant est de savoir comment l'appeler depuis le client? Nos programmes sont basés sur des procédures d'appel, donc la construction d'une bonne bibliothèque client RPC est facile, la construction d'une bonne bibliothèque client REST n'est pas tellement et dans la plupart des cas, vous allez simplement mapper à partir de votre API REST sur le serveur vers un ensemble de procédures dans votre client bibliothèque.

Pour cette raison, RPC me semble beaucoup plus simple et plus naturel aujourd'hui. Ce qui me manque vraiment, c'est un cadre cohérent qui facilite l'écriture de services RPC auto-descriptifs et interopérables. J'ai donc créé mon propre projet pour expérimenter de nouvelles façons de rendre le RPC plus facile pour moi et peut-être que quelqu'un d'autre le trouve utile aussi: 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 paramètres. Comme l'article l'explique, cela 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 des 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 conformité et non de qualité. Si vous voulez simplement appeler une fonction distante qui fait un calcul, cela n'a probablement aucun sens d'avoir des liens hypermédia pertinents dans la réponse, ni de différenciation de comportement basée sur le verbe HTTP utilisé. Ainsi, un tel appel a tendance à être plus proche de 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 uniquement pour l'adapter aux normes de conformité RESTful.

Pourquoi JSON RPC:

Dans le cas des API REST, nous devons définir un contrôleur pour chaque fonctionnalité / méthode dont nous pourrions avoir besoin. Par conséquent, si nous avons 10 méthodes que nous voulons accessibles à un client, nous devons écrire 10 contrôleurs pour interfacer la demande du client avec 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 s'il doit utiliser POST ou GET. Cela complique encore 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 JSON RPC, les choses sont grandement simplifiées car la plupart des serveurs JSONRPC fonctionnent sur des méthodes HTTP POST et le type de contenu est toujours application / json. Cela vous évite d'avoir à vous souvenir d'utiliser la méthode HTTP et les paramètres de contenu appropriés 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 disposez d'URL distinctes pour différentes fonctionnalités que le serveur souhaite exposer côté client. Par conséquent, vous pouvez intégrer ces URL.

La plupart de ces points sont discutables et dépendent entièrement des besoins d'une personne.

Je pense que, comme toujours, cela dépend ...

REST a l'énorme avantage d'un large soutien public et cela signifie beaucoup d'outils et de livres. Si vous devez créer une API utilisée par un grand nombre de consommateurs de différentes organisations, c'est la voie à suivre 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 d'une seule page qui doit parler à un backend, 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 à grain fin 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 la conception URL / Verb / Response, j'ai dû coder ce désordre en Javascript, le décodeur en Java et ensuite appeler la méthode réelle. Bien qu'il existe de nombreux outils pour cela, 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 moyennement complexe et comparez-le à une seule interface Java qui décrit les procédures distantes dans ce fichier. L'augmentation de la complexité est stupéfiante.

Je suis donc passé de REST à JSON-RPC pour la webapp d'une seule page. J'ai 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 d'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 bien être utilisés dans un modèle RPC. JSON RPC fonctionne sur HTTP, il 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.

REST est étroitement couplé à HTTP, donc si vous exposez uniquement votre API sur HTTP, alors REST est plus approprié pour la plupart (mais pas toutes) les situations. Cependant, si vous devez exposer votre API sur d'autres transports comme la messagerie ou les sockets Web, REST n'est tout simplement pas applicable.

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 avec les appels de méthode et les communications peut être facilement compris.

Le choix de l'approche la plus adaptée dépend des contraintes ou de l'objectif principal. Par exemple, dans la mesure où les performances sont un trait majeur, il est conseillé d'opter pour JSON-RPC (par exemple, High Performance Computing). Cependant, si l'objectif principal est d'être agnostique afin d'offrir une interface générique à déduire par d'autres, il est conseillé d'opter pour REST. Si vous devez atteindre ces deux objectifs, il est conseillé d'inclure les deux protocoles.

Le fait qui sépare réellement REST de JSON-RPC est qu'il suit une série de contraintes soigneusement pensées, confirmant la flexibilité architecturale. Les contraintes tiennent à ce que le client et le serveur puissent grandir indépendamment les uns des autres (des changements peuvent être effectués sans gâcher l'application du client), les appels sont sans état (l'état est considéré comme hypermédia), un uniforme est proposée pour les interactions, l'API est avancée sur un système en couches (Hall, 2010). JSON-RPC est rapide et facile à consommer, cependant, comme les ressources mentionnées ainsi que les paramètres sont étroitement couplés et il est susceptible de dépendre des verbes (api / addUser, api / deleteUser) utilisant GET / POST tandis que REST fournit des ressources faiblement couplées (api / utilisateurs) dans un HTTP. L'API REST dépend de plusieurs méthodes HTTP telles que GET, PUT, POST, DELETE, PATCH.

JSON (dénoté comme la notation d'objet JavaScript) étant un format léger d'échange de données, il est facile à lire et à écrire pour les humains. Il est facile pour les machines d'analyser et de 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 bien d'autres. Ces propriétés font de JSON un langage d'échange de données parfait et un meilleur choix.

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

Vous pouvez utiliser JSON-RPC avec "moins de verbe" (aucune méthode ) et conserver la standardisation minimale nécessaire pour l'ID sendo, les paramètres, les codes d' erreur et les messages d' avertissement . La norme 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 minimum d'informations, avec des contrats simples et solides.

Exemple

(à partir de cette réponse et du contexte didactique)

Lorsqu'il s'agit de REST, il est généralement utile de commencer par penser en termes de ressources. Dans ce cas, la ressource n'est pas seulement "compte bancaire" mais c'est une transaction de ce compte bancaire ... Mais JSON-RPC n'oblige pas le paramètre "méthode", tous sont encodés par "chemin" du noeud final.

• Dépôt REST avec POST /Bank/Account/John/Transactiondemande 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 crédits sur leur compte). Quelque chose comme {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. La convention concernant la requête (REST) ​​GET peut inclure le codage de l'id par "@id", donc pas besoin d'envoyer de JSON, mais toujours en utilisant JSON-RPC dans le pack de réponses.

Si vous demandez des ressources, l'API RESTful est meilleure par conception. Si vous demandez des données compliquées avec beaucoup de paramètres et de méthodes compliquées autres que le simple CRUD, alors RPC est la bonne voie à suivre.

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

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