Repos vs savon. A REST une meilleure performance?
J'ai lu quelques questions déjà postées ici concernant Soap and Rest Et je n'ai pas trouvé la réponse que je cherchais . Nous avons un système qui a été construit à l'aide de services Web Soap . Le système n'est pas très performant et il est en cours de discussionremplacer tous les services Web Soap pour les services Web REST . Quelqu'un a fait valoir que Rest a une meilleure performance . Je ne sais pas si cela est vrai . (C'était ma première question) En supposant que cela soit vrai, existe-t-il un inconvénient à utiliser REST au lieu de Soap? (Sommes-nous en train de perdre quelque chose?)
Merci d'avance.
La performance est un sujet vaste.
Si vous voulez parler de la charge du serveur, les performances de REST sont un peu meilleures car elles entraînent une surcharge minimale par rapport à HTTP. Habituellement, SOAP apporte une pile de gestionnaires et d’analyseurs différents (générés). Quoi qu’il en soit, la différence de performances n’est pas si grande en soi, mais le service RESTful est plus facile à faire évoluer puisque vous n’avez aucune session côté serveur.
Si vous parlez de la performance du réseau (c'est-à-dire de la bande passante), REST a de bien meilleures performances. Fondamentalement, c'est juste HTTP. Pas de frais généraux. Ainsi, si votre service fonctionne de toute façon sur HTTP, vous ne pouvez pas obtenir beaucoup moins lourd que REST. De plus, si vous codez vos représentations en JSON (par opposition à XML), vous économiserez beaucoup plus d'octets.
En bref, je dirais "oui", vous serez plus performant avec REST. En outre, cela (à mon avis) facilitera l'utilisation de votre interface par vos clients. Ainsi, non seulement votre serveur devient plus léger, mais également le client.
Cependant, quelques éléments à prendre en compte (puisque vous avez demandé «Que perdrez-vous?»):
Les interfaces RESTful ont tendance à être un peu plus "bavardes". Par conséquent, en fonction de votre domaine et de la façon dont vous concevez vos ressources, vous risquez de faire plus de requêtes HTTP.
SOAP a un support d'outils très large. Par exemple, les consultants l'adorent car ils peuvent utiliser des outils pour définir l'interface et générer le fichier wsdl, tandis que les développeurs l'adorent car ils peuvent utiliser un autre ensemble d'outils pour générer tout le code réseau de ce fichier wsdl. De plus, XML en tant que représentation comporte des schémas et des validateurs, qui peuvent parfois constituer un problème majeur. (JSON et REST ont des choses similaires à venir mais le support de l'outil est loin derrière)
SOAP nécessite l’analyse d’un message XML et de tout ce qui doit être envoyé et reçu.
REST utilise généralement quelque chose de beaucoup plus concis et facile à analyser, comme JSON.
Cependant, dans la pratique, la différence n’est pas si grande.
Construire un DOM à partir de XML est généralement un code superoptimisé ultra-rapide comme XERCES en C++ ou Java, alors que la plupart des analyseurs JSON sont dans la catégorie déroulante ou interprétée.
Dans un environnement réseau rapide (réseau local ou large bande), il n’ya pas beaucoup de différence entre l’envoi d’un ou deux K contre 10 à 15 k.
Vous formulez la question comme si REST et SOAP étaient en quelque sorte interchangeables dans un système existant. Ils ne sont pas.
Lorsque vous utilisez SOAP (une technologie), vous avez généralement un système défini dans les «méthodes», car vous avez en réalité affaire à RPC.
Lorsque vous utilisez REST (un style architectural, pas une technologie), vous créez alors un système défini en termes de 'ressources' et nullement en termes de méthodes. Il n'y a pas de mappage 1: 1 entre SOAP et REST. L'architecture du système est fondamentalement différente.
Ou parlez-vous simplement de "RPC via URI", qui est souvent confondu avec REST?
Une autre chose que les autres réponses semblent négliger est la prise en charge par REST de la mise en cache et des autres avantages de HTTP. Bien que SOAP utilise HTTP, il ne profite pas de l'infrastructure de prise en charge de HTTP. La liaison SOAP 1.1 définit uniquement l'utilisation du verbe POST. Ce problème a été résolu avec la version 1.2 lors de l'introduction des liaisons GET. Toutefois, cela peut poser problème si vous utilisez l'ancienne version ou si vous n'utilisez pas les liaisons appropriées.
La sécurité est une autre préoccupation clé en matière de performances. Les applications REST utilisent généralement TLS ou d'autres mécanismes de sécurité de la couche de session. TLS est beaucoup plus rapide que l'utilisation de mécanismes de sécurité au niveau de l'application tels que WS Security (WS Security souffre également de failles de sécurité ).
Cependant, je pense que ce sont pour la plupart des problèmes mineurs lorsque l'on compare les services basés sur SOAP et REST. Vous pouvez trouver des solutions aux problèmes de performances SOAP ou REST. Mon opinion personnelle est que ni SOAP, ni REST (par REST, je veux dire les services REST basés sur HTTP) ne conviennent aux services nécessitant un débit élevé et une latence faible. Pour ces types de services, vous voudrez probablement utiliser Apache Thrift, 0MQ ou la multitude d'autres protocoles binaires RPC.
Juste pour ajouter un peu à la réponse de wuher.
Http Header octets lorsque vous demandez cette page à l'aide du navigateur Web Chrome: 761
Octets requis pour l'exemple de message de savon dans wikipedia article: 299
Ma conclusion: Ce n’est pas la taille en octets sur le réseau qui permet à REST de fonctionner correctement.
Il est hautement improbable que la simple conversion d'un service SOAP en REST entraîne des avantages de performance significatifs. L'avantage REST a ceci est que si vous suivez les contraintes, vous pouvez tirer parti des mécanismes fournis par HTTP pour la production de systèmes évolutifs. La mise en cache et le partitionnement sont les outils de votre ceinture d’outils.
Je ne suis certainement pas un expert en ce qui concerne SOAP par rapport à REST, mais la seule différence de performances que je connaisse est que SOAP génère beaucoup de temps système lors de l'envoi/la réception de paquets, car il est basé sur XML un en-tête SOAP, etc. REST utilise l'URL + chaîne de requête pour effectuer une requête, et n'envoie donc pas beaucoup de Ko sur le réseau.
Je suis sûr qu'il y a d'autres personnes ici sur SO qui peuvent vous donner des réponses meilleures et plus détaillées, mais au moins j'ai essayé;)
Tout dépend. REST n'a pas vraiment de (bonne) réponse pour la situation dans laquelle les données de la demande peuvent devenir volumineuses. Je ressens ce point si je l’oublie parfois lorsqu’on parle de REST.
Imaginons un service qui vous permet de demander des données d’information pour des milliers d’articles différents.
Le développeur SOAP définirait une méthode qui vous permettrait de récupérer les informations pour un ou plusieurs éléments à votre guise ... en un seul appel.
Le développeur REST craint que son adresse URI ne devienne trop longue, de sorte qu'il définirait une méthode GET prenant un seul élément en tant que paramètre. Vous devrez alors appeler plusieurs fois, une fois pour chaque article, afin d’obtenir vos données. Propre et facile à comprendre ... mais.
Dans ce cas, il faudrait beaucoup plus d'allers-retours pour que le service REST accomplisse ce qui peut être fait avec un seul appel sur le service SOAP.
Oui, je sais qu'il existe des solutions de contournement concernant la gestion des données de demande volumineuses dans le scénario REST. Par exemple, vous pouvez intégrer des éléments dans le corps de votre demande. Mais ensuite, vous devrez définir avec soin (du côté du serveur et du côté client) comment cela doit être interprété. Dans ces situations, vous commencez à ressentir la douleur que REST n'est pas vraiment un standard (comme SOAP), mais plutôt une façon de faire les choses.
Pour les situations dans lesquelles une quantité relativement limitée de données est échangée, REST est un très bon choix. En fin de compte, il s'agit de la majorité des cas d'utilisation.
En général, un service Web basé sur REST est préféré en raison de sa simplicité, de ses performances, de son évolutivité et de la prise en charge de plusieurs formats de données. SOAP est préféré lorsque le service nécessite une prise en charge complète de la sécurité et de la fiabilité transactionnelle.
La réponse dépend vraiment des exigences fonctionnelles et non fonctionnelles. Poser les questions ci-dessous vous aidera à choisir.
REf: http://Java-success.blogspot.ca/2012/02/Java-web-services-interview-questions.html
Le service expose-t-il des données ou une logique métier? (REST est un meilleur choix pour exposer des données, SOAP WS pourrait être un meilleur choix pour la logique) . Les consommateurs et les fournisseurs de services ont-ils besoin d'un contrat formel? (SOAP a un contrat formel via WSDL) Devons-nous prendre en charge plusieurs formats de données? Devons-nous effectuer des appels AJAX? (REST peut utiliser XMLHttpRequest) L'appel est-il synchrone ou asynchrone? L'appel est-il en état ou sans état? (REST convient aux opérations CRUD statless) Quel niveau de sécurité est requis? (SOAP WS offre un meilleur support pour la sécurité) Quel est le niveau de support requis pour les transactions? (SOAP WS supporte mieux la gestion des transactions) Avons-nous une largeur de bande limitée? (SOAP est plus détaillé) Quel est le meilleur pour les développeurs qui construiront des clients pour le service? (REST est plus facile à implémenter, à tester et à maintenir)
Vous n'avez pas à choisir, les frameworks modernes vous permettent d'exposer des données dans ces formats avec un minimum de modifications. Respectez les exigences de votre entreprise et testez le chargement de l'implémentation spécifique pour comprendre le débit. Il n'y a pas de réponse correcte à cette question sans test de chargement correct pour un système spécifique.