it-swarm.dev

Avantages et inconvénients de l'architecture RESTful

La discussion la plus courante que j'ai vue concernant les avantages et les inconvénients de REST tend à encadrer cette discussion par rapport à SOAP. Je n'ai aucune expérience dans les deux cas. Je suis actuellement confronté à une décision qui me manque d'expérience est difficile à évaluer pour moi. Je commence à développer une application qui comprend plusieurs composants - principalement un aspect administratif qui permet au propriétaire d'administrer plusieurs sites - et une interface utilisateur accessible au public qui permet à l'utilisateur d'interagir avec les données détenues sur l'hôte. J'ai besoin d'évaluer les implications de permettre à la dernière partie d'être hébergée n'importe où et de communiquer avec la première via une architecture RESTful - ou d'exiger que les deux composants résident sur le même hôte. Quelles sont les principales implications du développement d'une architecture RESTful, en particulier en ce qui concerne sa capacité dans les domaines suivants:

1: Sécurité 2: Performance 3: Complexité de l'interface

EDIT: En regardant certaines des réponses à cette question - je dois clarifier. Je ne cherche pas une comparaison avec SOAP - plutôt un aperçu des applications REST vs applications où tous les composants résident sur un seul hôte. (Merci pour ces réponses) bien que!)

20
sunwukung

Compte tenu de ces domaines, je peux donner un aperçu général, mais je ne peux pas tirer vos conclusions pour vous. Il y a deux domaines principaux où les deux protocoles diffèrent:

  • Format du message
  • Découverte de service

Le format des messages est plus facile à comprendre. L'empaquetage SOAP pour les demandes et les réponses est assez lourd. Il y a l'enveloppe SOAP qui contient à la fois un en-tête et une section de corps. L'en-tête peut être utilisé par plusieurs filtres dans la chaîne de demande pour effectuer une sorte d'identification, d'autorisation, etc. Cependant, XML est coûteux à analyser, ce qui entraîne une certaine pénalité pour l'évolutivité de votre système. Tout dépend de la couche de traitement SOAP dans votre pile.

La découverte de service est l'endroit où vous aurez probablement le plus de conflits. REST par sa nature même fournit des points de terminaison prévisibles , et le contenu de la demande est une simple demande HTTP. L'avantage est qu'il n'y a pas de frais supplémentaires, et les utilisateurs finaux peuvent à peu près deviner comment faire ce dont ils ont besoin une fois qu'ils comprennent la structure URL de votre site. Bien sûr, les personnes naïves soucieuses de sécurité verront cela comme une faiblesse. Après tout, avec SOAP, vous devez consommer un WSDL pour savoir quels sont les points de terminaison. Bien sûr, avec SOAP on vous a donné le format de message entier afin que vous puissiez lancer des attaques plus ciblées.

Ventilés par catégories que vous avez données:

Sécurité

Aucun n'est intrinsèquement plus sûr que l'autre. Utilisez de bons principes de sécurité:

  • Chiffrer les communications
  • Assurez-vous d'authentifier et d'autoriser les utilisateurs avant de les traiter
  • Bonnes habitudes de codage pour éviter les attaques directes
  • Et ce n'est que la courte liste.

Souvenez-vous de l'obscurité! = Sécurité.

Performance

Les performances brutes et l'évolutivité iront à REST en raison de la demande suivant des protocoles HTTP simples. La plupart des piles SOAP utilisent l'analyse SAX (analyse basée sur les événements) qui améliore considérablement l'évolutivité des piles SOAP, mais il y a un impact mesurable sur la surcharge. SOAP a la surcharge de traitement HTTP normale en plus de la surcharge d'analyse XML. REST a juste la surcharge de traitement HTTP.

Complexité

Du point de vue du système, REST gagne. Il y a moins de pièces mobiles, une chaîne de demande plus légère, etc. Cela signifie qu'il est plus facile de devenir fiable.

Du point de vue du programmeur, SOAP peut gagner si le IDE ou le framework que vous utilisez fournit un bon support pour cela. Essentiellement, avec REST, il vous incombe d'exécuter le travail de prétraitement (authentification/autorisation/etc.) tandis qu'avec SOAP une grande partie de cela peut être accompli avec une chaîne de traitement enfichable.

Ma préférence

Je suis très à l'aise avec les requêtes HTTP et je sais comment fonctionne le Web. Par conséquent, l'approche REST est plus préférable pour moi. Cependant, je sais que certains de mes clients sont mal à l'aise avec cela. Ils ont lu un article du secteur dénonçant la sécurité de REST par rapport à SOAP, etc. En fin de compte, aucune approche ne garantit la sécurité. C'est à vous de vous assurer que l'application est aussi sécurisée qu'elle le devrait. De toute évidence, une application Web sociale n'exige pas (ou ne souhaite pas) autant de sécurité qu'une banque ou un système gouvernemental. De nombreuses piles SOAP incluent des processeurs que vous pouvez brancher pour fournir un semblant de sécurité, mais il est toujours de votre responsabilité de les rechercher et de les mettre en place.

13
Berin Loritsch
  1. Sécurité: Utilisez HTTPS. Cela s'applique aux deux.
  2. Performances: . REST est moins coûteux en CPU (moins d'analyse, de marshaling, de déballage). De plus, la mise en cache avec REST est un jeu d'enfant).
  3. Complexité: REST demande beaucoup moins en termes de configuration, c'est juste GET/POST après tout. SOAP nécessite beaucoup plus d'administration à maintenir (wsdl etc.), mais est un peu plus facile si votre IDE le prend en charge).

Je pense que SOAP est beaucoup trop gonflé quand vous pouvez faire la même chose avec REST et certains types de contenu/mime. En outre, SOAP apporte beaucoup de surcharge, en raison de sa nature de wrappers-wrappers et du fait qu'il est plus général et non limité à HTTP. SOAP est tentant d'utiliser si votre IDE le supporte correctement et que vous ne voulez pas apprendre HTTP. Mais pour moi, REST est beaucoup plus facile à utiliser et beaucoup plus plus web plus convivial.

De nos jours, il y a de très bonnes REST API à utiliser. Si vous êtes en Java, alors Jax-RS est vraiment cool. Pour certains, this est comme du porno .

12
Martin Wickman

Je pense que le plus grand avantage de REST est de rompre avec les architectures RPC. REST expose les ressources, pas les processus. Cela vous permet de créer un système lié de manière lâche, où les changements, les améliorations et même les défaillances d'une partie ont un impact limité (négatif) sur les autres parties.

Malheureusement, une mauvaise utilisation courante de REST est d'exposer vos structures de données internes (dans le pire des cas, c'est un CRUD de votre base de données, ugh). Cela en fait très La "bonne" utilisation est d'exposer des objets de haut niveau qui sont pertinents pour la partie du système que vous manipulez et de renvoyer généreusement des codes d'état d'erreur en cas d'incohérence.

Une autre partie souvent négligée de REST est l'idempotence de la plupart des verbes. Non seulement GET, mais aussi PUT et DELETE devraient être exactement le même résultat s'ils sont appliqués une ou plusieurs fois (vous êtes libre de renvoyer un 404 s'il est déjà supprimé, ou "pas de changement" si le client PUT le même) Cela conduit à des systèmes robustes et à moins d'interdépendance des interprétations exactes de la sémantique.

8
Javier

Les normes WS- * concernent principalement l'exécution de RPC sur SOAP/HTTP. Ainsi, toutes les réflexions qui ont porté sur CORBA et J2EE et leurs prédécesseurs sont pour la plupart passées au même genre de choses en XML. Cela signifie des choses comme les déclarations de type et les contrats de service, l'échange de métadonnées, la sécurité déclarative, etc. Toutes ces vraies choses "d'entreprise". Franchement, c'est sur-utilisé même dans l'entreprise.

Les gens qui construisent une application Web Internet comme vous, feraient certainement mieux d’utiliser une architecture RESTful. Presque toutes les plates-formes peuvent le consommer et le faire simplement et sans se soucier de la version de la spécification que vous utilisez et d'une myriade de bizarreries de conversion de type spécifique à l'outil, etc.

3
Jeremy

Seul gros avantage de SOAP par rapport aux implémentations actuelles de REST) est que SOAP est plus facile à utiliser - la plupart des clients RESTful nécessitent de comprendre l'interface et d'écrire un client quelconque. Pour SOAP, je pointe simplement wsdl.exe dessus et il génère des classes pour moi.

0
Wyatt Barnett