web-dev-qa-db-fra.com

Différences entre les services Web entre REST et RPC

J'ai un service Web qui accepte les paramètres JSON et des URL spécifiques pour les méthodes, par exemple:

http://IP:PORT/API/getAllData?p={JSON}

Ce n'est certainement pas REST car ce n'est pas sans état. Il prend en compte les cookies et a sa propre session.

Est-ce RPC? Quelle est la différence entre RPC et REST?

web-servicesrestrpc
51
Mazmart

Vous ne pouvez pas faire une séparation claire entre REST ou RPC simplement en regardant ce que vous avez posté.

Une contrainte de REST est que cela doit être sans état. Si vous avez une session, vous avez l'état et vous ne pouvez pas appeler votre service RESTful.

Le fait que vous ayez une action dans votre URL (c'est-à-dire getAllData) est une indication pour RPC. Dans REST vous échangez des représentations et l'opération que vous effectuez est dictée par les verbes HTTP. En outre, dans REST, Négociation du contenu n'est pas effectuée avec un ?p={JSON} paramètre.

Je ne sais pas si votre service est RPC, mais ce n'est pas RESTful. Vous pouvez en apprendre davantage sur la différence en ligne, voici un article pour vous aider à bien démarrer: Démystifier les mythes de RPC & REST . Vous savez mieux ce qui se trouve dans votre service, comparez ses fonctions à celles de RPC et tirez vos propres conclusions.

36
Bogdan

Prenons l'exemple suivant d'API HTTP qui modélise les commandes passées dans un restaurant.

  • L'API RPC pense en termes de "verbes", exposant la fonctionnalité de restaurant en tant qu'appels de fonction acceptant des paramètres, et invoquant ces fonctions via le verbe HTTP qui semble le plus approprié - un 'get' pour une requête, etc., mais le nom du verbe est purement accessoire et n'a pas d'incidence réelle sur les fonctionnalités réelles, car vous appelez un autre URL à chaque fois . Les codes de retour sont codés à la main et font partie du contrat de service.
  • L'API REST , en revanche, modélise les différentes entités du domaine à problème en tant que ressources et utilise des verbes HTTP pour représenter les transactions sur ces ressources - POST pour créer, PUT pour mettre à jour et GET pour lire. Tous ces verbes, invoqués sur la même URL , fournissent des Les codes de retour HTTP communs sont utilisés pour indiquer l’état des demandes.

Passer une commande:

Récupération d'une commande:

Mise à jour d'une commande:

Exemple tiré de sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc

55
JerryGoyal

Comme d'autres l'ont dit, une différence essentielle est que REST est centré sur le nom et RPC est centré sur le verbe. Je voulais simplement inclure ceci tableau clair d'exemples démontrant que :

 --------------------------- + ----------------- -------------------- + -------------------------- 
 Opération                 | RPC (opération)                     | REST (ressource)
 --------------------------- + ----------------- -------------------- + -------------------------- 
 Inscription | POST/inscription | POST/personnes 
 -------------------- ------- + ----------------------------------------- + ---- ---------------------- 
 Démissionner | POST/démissionner | SUPPRIMER/personnes/1234 
 --------------------------- + -------------------- ----------------- + -------------------------- 
 Lire personne | GET/readPerson? personid = 1234 | GET/persons/1234 
 --------------------------- + - ----------------------------------- + -------------- ------------ 
 Lire la liste d'éléments de la personne | GET/readUsersItemsList? Userid = 1234 | GET/persons/1234/items 
 -------- ------------------- + ------------------------------ ------- + -------------------------- 
 Ajouter un élément à la liste des personnes | POST/addItemToUsersItemsList | POST /persons/1234/items[.____.orrect. ------------------------- ------ + ------------------------------------- + ----- ------------------ --- 
 Élément de mise à jour | POST/modifyItem | PUT/items/456 
 --------------------------- + ------------------------------------- + ----------- --------------- 
 Supprimer l'élément | POST/removeItem? ItemId = 456 | DELETE/items/456 
 --------------------------- + ---------------------- --------------- + --------------------------

Remarques

  • Comme le montre le tableau, REST a tendance à utiliser les paramètres de chemin d’URL pour identifier des ressources spécifiques).
    (par exemple. GET /persons/1234), alors que RPC a tendance à utiliser des paramètres de requête pour les entrées de fonction
    (par exemple. GET /readPerson?personid=1234).
  • Le tableau ne montre pas comment REST API) gérerait le filtrage, ce qui impliquerait généralement des paramètres de requête (par exemple, GET /persons?height=tall).
  • De plus, avec l’un ou l’autre système, lorsque vous créez/mettez à jour des opérations, des données supplémentaires sont probablement transmises via le corps du message (par exemple, lorsque vous effectuez POST /signup ou POST /persons, vous incluez des données décrivant la nouvelle personne).
  • Bien entendu, rien de tout cela n’est gravé dans le marbre, mais cela vous donne une idée de ce que vous êtes susceptible de rencontrer et de la manière dont vous pourriez organiser votre propre API par souci de cohérence. Pour plus d'informations sur REST Conception de l'URL, voir cette question .
14
MarredCheese

C'est RPC en utilisant http . Une implémentation correcte de REST devrait être différente de RPC. Pour avoir une logique de traitement des données, telle qu'une méthode/fonction, c'est RPC. GetAllData () est une méthode intelligente. REST ne peut pas avoir d'intelligence, il doit s'agir de données de vidage pouvant être interrogées par une intelligence externe .

De nos jours, la plupart des implémentations sont RPC, mais beaucoup l'appellent à tort REST car ils constatent qu'ils n'utilisent pas XML/Soap mais HTTP + json. REST avec HTTP est le sauveur et SOAP avec XML le méchant. Donc, votre confusion est justifiée et vous avez raison, ce n'est pas REST.

Le protocole HTTP ne fait pas une implémentation de REST. Les méthodes REST (GET, POST, PUT, PATCH, DELETE) et RPC (GET + POST) peuvent être développées via HTTP (par exemple: via un projet d'API Web dans Visual Studio).

RPC est vieux et tous les enfants de l’école savent ce qu’il est et la plupart des REST développés finissent par être RPC (HTTP + Json), ce qui est compréhensible. Mais quel est REST Le modèle de maturité Richardson est présenté ci-dessous (résumé). Seul le niveau 3 correspond à RESTful.

  • Niveau 0: POST Http
  • Niveau 1: chaque ressource/entité a un URI (mais toujours uniquement POST)
  • Niveau 2: Les deux POST et GET peuvent être utilisés
  • Niveau 3 (REST): Utilise HATEOAS (hyper media links) ou en d’autres termes, des liens auto-exploratoires

par exemple niveau 3:

  1. Le lien indique que cet objet peut être mis à jour de cette façon et ajouté de cette façon
  2. Le lien indique que cet objet ne peut être lu que et c'est comme cela que nous le faisons.

Vous avez créé des sites Web pouvant être utilisés par des humains. Mais pouvez-vous également créer des sites Web utilisables par des machines? C'est là que réside l'avenir, et RESTful Web Services vous montre comment le faire.

14
Blue Clouds

La meilleure description de REST est de travailler avec les ressources, où RPC concerne davantage les actions.

REST signifie Représentational State Transfer. C'est un moyen simple d'organiser les interactions entre systèmes indépendants. Les applications RESTful utilisent couramment des requêtes HTTP pour publier des données (créer et/ou mettre à jour), lire des données (par exemple, effectuer des requêtes) et supprimer des données. Ainsi, REST peut utiliser HTTP pour les quatre opérations CRUD (Créer/Lire/Mettre à jour/Supprimer).

RPC est essentiellement utilisé pour communiquer entre les différents modules afin de répondre aux demandes des utilisateurs. par exemple. En openstack, nova, regard et neutron fonctionnent ensemble lors du démarrage d’une machine virtuelle.

7
IRSHAD

Je dirais ainsi:

Est-ce que mon entité détient/possède les données? Puis RPC: voici une copie de certaines de mes données, manipulez la copie que je vous ai envoyée et renvoyez-moi une copie de votre résultat.

L'entité appelée détient-elle/possède-t-elle les données? Puis REST: soit (1) montrez-moi une copie de certaines de vos données, soit (2) manipulez certaines de vos données.

En fin de compte, il s'agit de savoir quel "côté" de l'action possède/détient les données. Et oui, vous pouvez utiliser REST verbiage pour parler à un système basé sur RPC, mais vous continuerez à effectuer une activité RPC en même temps.

Exemple 1: j'ai un objet qui communique avec un magasin de base de données relationnelle (ou tout autre type de magasin de données) via un DAO. Cela a du sens d’utiliser REST pour cette interaction entre mon objet et l’objet d’accès aux données qui peut exister en tant qu’API. Mon entité ne possède pas/ne détient pas les données, la base de données relationnelle magasin de données relationnel) fait.

Exemple 2: Je dois faire beaucoup de mathématiques complexes. Je ne veux pas charger un tas de méthodes mathématiques dans mon objet, je veux juste transmettre des valeurs à quelque chose d'autre qui peut faire toutes sortes de maths et obtenir un résultat. Le style RPC prend alors tout son sens, car l’objet/entité mathématique exposera à mon objet toute une série d’opérations. Notez que ces méthodes peuvent toutes être exposées en tant qu'API individuelles et que je peux appeler l'une d'elles avec GET. Je peux même prétendre que cela est RESTful parce que j'appelle via HTTP GET mais vraiment sous les couvertures c'est RPC. Mon entité possède/détient les données, l'entité distante ne fait que manipuler les copies des données que je lui ai envoyées.

3
John Tullis

Sur HTTP, ils finissent tous deux par n'être que des objets HttpRequest et ils attendent tous deux un objet HttpResponse. Je pense que l'on peut continuer à coder avec cette description et s'inquiéter de quelque chose d'autre.

0
acmoune

Voici comment je les comprends et les utilise dans différents cas d'utilisation:

Exemple: gestion de restaurant

cas d'utilisation pour REST : gestion des commandes

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

Pour la gestion des ressources, REST est propre. Un point de terminaison avec des actions prédéfinies. Il peut être utilisé pour exposer au monde des instances de base de données (Sql ou NoSql).

Exemple d'implémentation:

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

Exemple de framework: Falcon pour python.

cas d'utilisation pour RPC : gestion des opérations

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

Pour les travaux analytiques, opérationnels, non réactifs, non représentatifs et axés sur l'action, RPC fonctionne mieux et il est très naturel de penser fonctionnel.

Exemple d'implémentation:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

Exemple de structure: Flask pour python

0
Ali Khosro