Différences de service Web entre REST et RPC

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

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

Ce n'est certainement pas REST car il n'est pas apatride. Il prend en compte les cookies et a sa propre session.

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

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

Une contrainte de REST est qu'il doit être sans état. Si vous avez une session, vous avez un état, vous ne pouvez donc pas appeler votre service RESTful.

Le fait que vous ayez une action dans votre URL (ie getAllData) est une indication vers RPC. Dans REST, vous échangez des représentations et l'opération que vous effectuez est dictée par les verbes HTTP. De plus, dans REST, la négociation de contenu n'est pas effectuée avec un?p={JSON} paramètre.

Je ne sais pas si votre service est RPC, mais il n'est pas RESTful. Vous pouvez en apprendre davantage sur la différence en ligne, voici un article pour vous aider à démarrer: Démystifier les mythes du RPC et du REST . Vous savez mieux ce qu'il y a à l'intérieur de votre service, alors comparez ses fonctions à ce qu'est RPC et tirez vos propres conclusions.

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

• L' API RPC pense en termes de "verbes", exposant la fonctionnalité du restaurant comme des appels de fonction qui acceptent des paramètres, et invoque ces fonctions via le verbe HTTP qui semble le plus approprié - un "get" pour une requête, et ainsi de suite, mais le nom du verbe est purement accessoire et n'a aucune incidence réelle sur la fonctionnalité réelle, puisque vous appelez une URL différente à 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ématique en tant que ressources et utilise des verbes HTTP pour représenter les transactions par rapport à ces ressources - POST pour créer, PUT pour mettre à jour et GET pour lire. Tous ces verbes, appelés sur la même URL , fournissent des fonctionnalités différentes. Les codes de retour HTTP courants sont utilisés pour transmettre l'état des demandes.

Passer une commande:

• RPC: http: // MyRestaurant: 8080 / Orders / PlaceOrder (POST: {objet Tacos})
• REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (POST: {Tacos object})

Récupération d'une commande:

• RPC: http: // MyRestaurant: 8080 / Orders / GetOrder? OrderNumber = asdf (GET)
• REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (GET)

Mettre à jour une commande:

• RPC: http: // MyRestaurant: 8080 / Orders / UpdateOrder (PUT: {objet Pineapple Tacos})
• REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (PUT: {Pineapple Tacos object})

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

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

--------------------------- + ---------------------- --------------- + --------------------------
  Fonctionnement                  | RPC (opération)                      | REST (ressource)
--------------------------- + ---------------------- --------------- + --------------------------
 Inscription | POST / inscription | POSTE / personnes           
--------------------------- + ---------------------- --------------- + --------------------------
 Démissionner | POST / démissionner | SUPPRIMER / personnes / 1234    
--------------------------- + ---------------------- --------------- + --------------------------
 Lire personne | GET / readPerson? Personid = 1234 | GET / personnes / 1234       
--------------------------- + ---------------------- --------------- + --------------------------
 Lire la liste des objets de la personne | GET / readUsersItemsList? Userid = 1234 | GET / personnes / 1234 / items
--------------------------- + ---------------------- --------------- + --------------------------
 Ajouter un élément à la liste des personnes | POST / addItemToUsersItemsList | POST / personnes / 1234 / items
--------------------------- + ---------------------- --------------- + --------------------------
 Mettre à jour l'élément | POST / modifyItem | PUT / articles / 456          
--------------------------- + ---------------------- --------------- + --------------------------
 Supprimer l'élément | POST / removeItem? ItemId = 456 | SUPPRIMER / items / 456       
--------------------------- + ---------------------- --------------- + --------------------------

Remarques

• Comme le montre le tableau, REST a tendance à utiliser des paramètres de chemin d'URL pour identifier des ressources spécifiques
  (par exemple GET /persons/1234), tandis 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 une API REST gérerait le filtrage, qui impliquerait généralement des paramètres de requête (par exemple GET /persons?height=tall).
• Il n'est pas non plus montré comment avec l'un ou l'autre système, lorsque vous effectuez des opérations de création / mise à jour, des données supplémentaires sont probablement transmises via le corps du message (par exemple, lorsque vous faites POST /signupou POST /persons, vous incluez des données décrivant la nouvelle personne).
• Bien sûr, 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 façon dont vous pourriez vouloir organiser votre propre API pour la cohérence. Pour plus d'informations sur la conception d'URL REST, consultez cette question .

C'est RPC utilisant http . Une implémentation correcte de REST doit être différente de RPC. Avoir une logique pour traiter les données, comme une méthode / fonction, est RPC. getAllData () est une méthode intelligente. REST ne peut pas avoir d'intelligence, il doit s'agir de données de vidage qui peuvent être interrogées par une intelligence externe .

La plupart des implémentations que j'ai vues ces jours-ci sont RPC, mais beaucoup l'appellent à tort REST. 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 n'effectue pas d'implémentation de REST. Les deux REST (GET, POST, PUT, PATCH, DELETE) et RPC (GET + POST) peuvent être développés via HTTP (par exemple: via un projet d'API Web dans Visual Studio).

Bien, mais qu'est-ce que REST alors? Le modèle de maturité de Richardson est présenté ci-dessous (résumé). Seul le niveau 3 est RESTful.

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

ex: niveau 3 (HATEOAS):

1. Link indique que cet objet peut être mis à jour de cette façon et ajouté de cette façon.

2. Link indique que cet objet ne peut être lu et c'est ainsi que nous le faisons.

   De toute évidence, l'envoi de données ne suffit pas pour devenir REST, mais la manière d'interroger les données doit également être mentionnée. Mais là encore, pourquoi les 4 étapes? Pourquoi ne peut-il pas être simplement l'étape 4 et l'appeler REST? Richardson vient de nous donner une approche étape par étape pour y arriver, c'est tout.

Vous avez créé des sites Web qui peuvent ê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 les services Web RESTful vous montrent comment le faire.

• Ce livre RESTful Web Services aide
• Une lecture très intéressante RPC vs REST

PS: REST est très populaire, tout comme les tests automatisés, mais quand il s'agit d'exemples du monde réel ... eh bien ...

REST est mieux décrit pour travailler avec les ressources, alors que RPC est plus sur les actions.

REST signifie Representational State Transfer. C'est un moyen simple d'organiser les interactions entre des systèmes indépendants. Les applications RESTful utilisent généralement 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 pour répondre aux demandes des utilisateurs. Par exemple, dans openstack, comme comment nova, regard et neutron fonctionnent ensemble lors du démarrage d'une machine virtuelle.

Je dirais ainsi:

Mon entité détient / est-elle propriétaire des données? Puis RPC: voici une copie de certaines de mes données, manipulez la copie de données que je vous envoie et renvoyez-moi une copie de votre résultat.

L'entité appelée détient / est-elle propriétaire des données? Puis REST: soit (1) montrez-moi une copie de certaines de vos données ou (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 le verbiage REST pour parler à un système basé sur RPC, mais vous ferez toujours une activité RPC ce faisant.

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. Il est logique d'utiliser le style 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 / ne détient pas les données, contrairement à la base de données relationnelle (ou au magasin de données non relationnel).

Exemple 2: J'ai besoin de faire beaucoup de calculs complexes. Je ne veux pas charger un tas de méthodes mathématiques dans mon objet, je veux juste passer des valeurs à quelque chose d'autre qui peut faire toutes sortes de mathématiques et obtenir un résultat. Ensuite, le style RPC a du sens, car l'objet / l'entité mathématique exposera à mon objet tout un tas d'opérations. Notez que ces méthodes peuvent toutes être exposées en tant qu'API individuelles et que je pourrais appeler l'une d'entre elles avec GET. Je peux même prétendre que c'est RESTful parce que j'appelle via HTTP GET, mais en réalité, c'est RPC. Mon entité possède / détient les données, l'entité distante effectue simplement des manipulations sur les copies des données que je lui ai envoyées.

Sur HTTP, ils finissent tous deux par n'être que des HttpRequestobjets et ils attendent tous les deux un HttpResponseobjet en retour. Je pense que l'on peut continuer à coder avec cette description et s'inquiéter d'autre chose.

Il y a un tas de bonnes réponses ici. Je vous renvoie tout de même à ce blog google car il discute très bien des différences entre RPC et REST et capture quelque chose que je n'ai lu dans aucune des réponses ici.

Je citerais un paragraphe du même lien qui m'a marqué:

REST lui-même est une description des principes de conception qui sous-tendent HTTP et le World Wide Web. Mais comme HTTP est la seule API REST commercialement importante, nous pouvons surtout éviter de discuter de REST et nous concentrer uniquement sur HTTP. Cette substitution est utile car il y a beaucoup de confusion et de variabilité dans ce que les gens pensent que REST signifie dans le contexte des API, mais il y a beaucoup plus de clarté et d'accord sur ce qu'est HTTP lui-même. Le modèle HTTP est l'inverse parfait du modèle RPC - dans le modèle RPC, les unités adressables sont des procédures et les entités du domaine du problème sont cachées derrière les procédures. Dans le modèle HTTP, les unités adressables sont les entités elles-mêmes et les comportements du système sont cachés derrière les entités en tant qu'effets secondaires de leur création, mise à jour ou suppression.

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 vu un moyen d'exposer une DB (Sql ou NoSql) ou des instances de classe au monde.

Exemple d'implémentation:

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

Exemple de cadre: 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 emplois analytiques, opérationnels, non réactifs, non représentatifs, basés sur l'action, le 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 cadre: Flask pour python