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?
Réponses:
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.
Passer une commande:
Récupération d'une commande:
Mettre à jour une commande:
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
GET /persons/1234), tandis que RPC a tendance à utiliser des paramètres de requête pour les entrées de fonction GET /readPerson?personid=1234).GET /persons?height=tall).POST /signupou POST /persons, vous incluez des données décrivant la nouvelle personne).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.
ex: niveau 3 (HATEOAS):
Link indique que cet objet peut être mis à jour de cette façon et ajouté de cette façon.
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.
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.
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