REST vs JSON-RPC? [fermé]


251

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.


29
REST est définitivement la réponse populaire en ce moment. Je ne suis pas convaincu que ce soit toujours la bonne réponse. Il pourrait y avoir une incompatibilité d'impédance entre une API REST centrée sur les ressources et un domaine problématique qui est intrinsèquement basé sur une tâche ou un flux de travail. Si vous constatez que vous devez effectuer différents types de PATCH sur la même ressource ou que certaines tâches ne sont pas mappées sur une ressource spécifique, vous devez commencer à plier le paradigme REST. Utilisez-vous des actions / commandes comme ressources. Différenciez-vous les types de commandes dans l'en-tête Content-Type en tant que paramètres? Je ne suis pas sûr qu'il existe une réponse unique.
Landon Poch

27
JSON-RPC est simple et cohérent, un plaisir à utiliser.
dnault

1
Son août 2015, j'ai implémenté à la fois le client et le serveur en utilisant REST, les 2 premiers jours apprenaient, puis j'ai compris pourquoi c'était populaire. C'était une vraie joie une fois qu'une petite application est créée, le client n'a vraiment pas de travail pour se souvenir des différents chemins d'url, le serveur sur node.js et le client en javascript partageaient la même structure (chemins d'url) pour communiquer. Hou la la! c'était très rapide, le produit a été livré en seulement 15 jours, même en écrivant à partir de zéro. REST est le chemin à parcourir. Notez également que Popular Apache CouchDB utilise REST, une excellente base de données, sont très fiers qu'ils l'aient également fait dans REST. En simple, REST est RIGHT (correct) avec une interface propre.
Manohar Reddy Poreddy

6
Cela dépend des contraintes que vous avez ou de votre objectif principal. Par exemple, si les performances sont un aspect majeur, votre chemin à parcourir est JSON-RPC (par exemple, le calcul haute performance). Si votre objectif principal est d'être agnostique afin de fournir une interface générique à interpréter par d'autres, votre chemin à parcourir est REST. Si vous voulez les deux objectifs, vous devez inclure les deux protocoles. Vos besoins définissent la solution.
Stathis Andronikos

@StathisAndronikos Vous avez raison, mon objectif principal était la facilité d'utilisation et de bonnes performances pour les applications web (pas HPC).
Ali Shakiba

Réponses:


221

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.


20
Qu'entendez-vous par "il est obligatoire d'incorporer des liens annotés avec des types de relations de lien qui véhiculent des significations .."?
pjz

129
"Les clients doivent connaître les noms des procédures" - ce n'est pas un argument car avec REST, ce nom est codé en dur dans l'URI au lieu de passer en paramètre. Sinon, le serveur ne saura pas quelle méthode il doit exécuter.
Centurion

44
"Ce n'est pas si facile de changer les signatures de procédure ... côté serveur sans casser les implémentations client", cela est également discutable. REST et JSON-RPC ne sont pas tous deux SOAP et n'ont pas WSDL qui décrit les services Web existants et leurs types afin qu'ils puissent être utilisés pour des changements dynamiques côté client. Donc, de toute façon, si vous changez de service Web, vous devez changer de client. Sinon, vous devez utiliser SOAP.
Centurion

64
J'ai codé plusieurs applications et je n'ai pas vu de services Web flexibles. Si vous modifiez le backend et les services Web, le client doit toujours être refactorisé / mis à jour pour répondre aux nouvelles exigences. Et j'ai mentionné SOAP et parce qu'il a quelque chose qui donne de la flexibilité, comme WSDL, vous pouvez donc automatiser quelque chose et avoir plus de flexibilité parce que vous pouvez obtenir des informations sur l'ensemble de résultats, les types de données et les services Web disponibles. REST et d'autres n'en ont pas du tout. Ainsi, ni REST, ni JSON-RPC, ni aucun autre type de service Web ne vous donneront de magie qui éliminerait le besoin de mise à jour manuelle du client.
Centurion

15
Pour moi, mon équipe actuelle et les équipes précédentes, les services Web RESTful sont destinés aux applications de type CRUD. Concernant "Réécrivons-nous les navigateurs à chaque fois que quelque chose change sur le serveur?" - non, parce que les navigateurs ne sont que des exécuteurs HTTP, ils n'ont rien à voir avec la logique métier, que le programme client doit implémenter (afficher des écrans, effectuer des tâches connexes). Il semble que nous ayons commencé la guerre des flammes, mais en général, j'aurais aimé avoir une autre source solide pour les services Web RESTfull avec un flux d'utilisation pratique, avec une flexibilité magique à laquelle vous faites référence. Pendant ce temps, beaucoup de déclarations sont trop vagues.
Centurion

163

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.


30
Cette réponse montre l'idée fausse trop habituelle de ce qu'est réellement REST. REST n'est certainement pas seulement un mappage de CRUD aux méthodes HTTP. L'idée qu'il est difficile "d'ajouter une autre méthode" indique clairement que REST est mal compris comme RPC sur HTTP, ce qu'il n'est pas du tout. Essayez de lire le blog de Roy Fieldings ou sa dissertation - Google vous aidera à le trouver - vous ne décrivez pas du tout REST dans votre réponse.
nepdev

68
Je suis une personne très pratique. Toutes les descriptions de REST que j'ai lues commencent clairement par un mappage de CRUD aux méthodes HTTP. Plus est autorisé à être ajouté théoriquement, mais en pratique, non. Par exemple, j'ai récemment voulu implémenter PATCH pour les appareils Android, mais j'ai constaté qu'Android n'autorise pas PATCH, j'ai donc utilisé POST avec une action explicitement définie à cet effet dans l'URI. Fondamentalement, le REST pur ne fera pas les travaux dont j'ai besoin, donc j'utilise ce qui fonctionne.
Bruce Patin

4
Donc @BrucePatin, dans votre version "REST" vous avez un contrôleur avec quatre méthodes publiques qui mappent 1 à 1 avec GET | PUT | POST | DELETE? Certains frameworks font cela mais ce n'est pas REST. Les verbes HTTP font de vagues affirmations abstraites sur la sémantique d'une demande donnée. Vous devez mapper vos points de terminaison dans ces classes de manière appropriée. GET pourrait correspondre à de nombreux points d'extrémité différents, tout comme les autres. Il n'y a en fait aucune raison pour laquelle vous ne pouvez pas implémenter REST-ful JSON-RPC sur HTTP.
spinkus

5
Il y a une très bonne raison. Je pourrais vouloir plusieurs dizaines d'actions, et j'ai déjà rencontré une utilisation courante (Android) qui ne prend même pas en charge PATCH. Ça tue le froid. Je préfère être cohérent plutôt que de devoir traiter de plusieurs exceptions à la règle. En général, je n'utiliserai désormais que GET, POST et DELETE. PUT ne permet pas les commentaires que je souhaiterais sur une opération de mise à jour. J'utilise POST pour presque tout. En ce qui concerne la mise en cache, elle a causé de nombreux problèmes en renvoyant d'anciennes données. En ce qui concerne la mise des paramètres dans POST, ASP.NET le gère déjà automatiquement à partir d'objets JSON automatiques.
Bruce Patin

22
Je crois que les querelles sur ce qu'est vraiment REST ne font que souligner vos commentaires et mettent en évidence une lacune majeure de REST. Sur le plan conceptuel, il est difficile de trouver deux personnes entièrement d'accord sur ce qu'est RESTful. Quoi qu'il en soit, cela n'a pas d'importance car aucun service ne doit être RPC ou REST non documenté. S'il est documenté, le développeur qui l'utilise ne devrait avoir aucun problème.
Agile Jedi

29

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


1
+1 pour la référence faisant autorité, le gars qui devrait savoir ... Il est difficile de plaider pour RPC sur HTTP après cela, sans le reconnaître comme un hack / work-around ....
RJB

9
Vous venez de faire référence à quelque chose de 2000. C'est plus un argument philosophique pour REST contre RPC. Sémantiquement et en appliquant un modèle RPC, vous pouvez facilement considérer l'URI comme la "procédure" et les paramètres codés comme ... eh bien ... les paramètres. L'un ou l'autre modèle fonctionnerait très bien sur HTTP. Idem avec SOAP, RAILS ou tout autre nombre de modèles / protocoles qui ont été superposés sur HTTP. Peu importe tant que vous proposez une API cohérente qui ne rompt pas son contrat.
Agile Jedi

Aurélien, pourriez-vous justifier, pourquoi REST est plus facile à intégrer avec des composants logiciels indépendants? Pour moi, que vous utilisiez l'API RESTful ou RPC, le logiciel client doit connaître le format indiqué par votre API.
Alexey

1
@Alexey Cet argument était relatif à l'apatridie. Il est plus facile d'intégrer une machine à café dont l' API est CREATE CUP, qu'un autre qui contiendrait INSERT COIN, SELECT COFFEE, SELECT SUGARet START. Dans la deuxième API, car cela dépend de l'état de la machine, vous devez être très prudent avec la séquence des appels de procédure.
Aurélien

1
HTTP en tant que protocole RPC est REST. Votre interprétation incorrecte est donc choquante dans l'autre sens.
Tiberiu-Ionuț Stan

24

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


3
ce n'est pas LÉGÈREMENT plus difficile, mais plutôt extrêmement plus difficile. J'essaie de le comprendre depuis environ 4 mois, et je n'ai toujours pas une bonne idée de la façon d'écrire un service qui ne se transforme pas en un RPC sans état sur http à l'aide de json, et je ne suis toujours pas convaincu il y a une vraie différence entre "REST" et ce que je viens de dire
Austin_Anderson

19

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


C'est génial de trouver un esprit apparenté! Je travaille sur quelque chose de similaire ici: github.com/dnault/therapi-json-rpc
dnault

:) Je vais y jeter un œil
idelvall

1
D'accord avec ça. REST fonctionne bien pour les API CRUD, car vous disposez de l'évident POST / GET / PUT / DELETE [PoGPuD? ;)] cartographie. Cependant, si votre API ne s'adapte pas confortablement à ces verbes, JSON-RPC peut être une bonne option car les verbes vont juste semer la confusion. Alors oui, qui l'utilise et pourquoi est un facteur important.
Algy Taylor

1
Exactement - REST est le royaume des noms, JSON-RPC est des verbes.
Rob Grant

16

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)


15

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


Découvrez OpenRPC, cela devrait résoudre votre besoin de "services RPC faciles à écrire qui sont auto-descriptifs et interopérables"
Belfordz

11

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.


1
+1 pour les niveaux 0, 1 et 2. Cependant, je n'ai jamais vu une implémentation réussie de HATEOS, mais j'ai vu deux tentatives misérablement échouées.
mjhm

8

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.


3

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.


1
Cette réponse m'a fait réaliser les similitudes entre GraphQL et JSON-RPC et pourquoi GraphQL devient un choix populaire pour les SPA.
Dennis

OpenRPC est l'équivalent d'OpenAPI / Swagger, mais pour JSON-RPC
Belfordz

1

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.


2
REST est un style architectural et non dépendant du protocole.
Mark Cidade

4
Vous avez raison REST est un principe architectural. Cependant, sa base théorique a été fortement influencée par le protocole HTTP et malgré la revendication d'applicabilité universelle, il n'a trouvé aucune application pratique au-delà du domaine Web. Donc, il est sûr de dire que lorsque quelqu'un mentionne REST, il se réfère aux services Web et non au principe architectural.
dtoux

1

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.


"Il est facile pour les machines d'analyser" - j'ai vu beaucoup de JSON cassé (par exemple des citations non
échappées

1

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.



0

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.


Il s'agit d'une très grande simplification excessive du sujet. Pourquoi, en particulier, est-il «meilleur par conception»? JSON-RPC peut être aussi simple ou aussi compliqué que vous le souhaitez, et donc l'argument selon lequel il est "meilleur" pour "beaucoup de paramètres et de méthodes compliquées" est également faux. Ce n'est ni meilleur ni pire dans ce domaine.
Belfordz

Peu importe que le RPC utilise JSON ou protobuf ou XML pour sérialiser les données. Le point clé est l'API comme je l'ai dit. Je ne veux pas dire que l'un est meilleur que l'autre dans tous les cas. Mais je pense que les paramètres et les méthodes importent lorsque vous choisissez entre les deux implémentations. S'ils sont simples, l'API RESTful est bien comprise par la plupart des programmeurs et vous pouvez facilement construire la requête http. S'ils sont compliqués, RPC est plus capable d'exprimer de telles API, et votre IDE et votre compilateur peuvent vous aider.
Adrian Liu

-1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.