Comment convaincre mon patron d'utiliser REST sur SOAP?
Nous devons créer une API pour notre système. Comment convaincre mon patron que REST est une meilleure option que SOAP (ou XML-RPC)?
Je dis REST est ...
- plus facile à mettre en œuvre et à entretenir
- pas grand chose de nouveau à apprendre - simple vieux HTTP
- beaucoup de gens l'ont choisi Yahoo ~ Facebook ~ Twitter
- sera beaucoup plus rapide à coder
Mon patron dit SOAP est ...
- plus riche et plus expressif
- c'est tout XML standard (SOAP, WSDL, UDDI) - et sera donc plus facile à consommer
- bien standardisé que REST
- Google utilise beaucoup de SOAP
- il est important de respecter les normes SOAP que de créer un schéma XML personnalisé dans REST
D'un gars qui a utilisé les deux SOAP et REST largement ...
BOSS dit SOAP est ...
richer and more expressive
Chaque fois que quelqu'un dit qu'un produit est "riche", je veux devenir gravement malade. Je ne peux pas penser à un commentaire plus cliché à faire sur une technologie ou une plate-forme. En gros, vous dites "Je pense que ce produit est génial, mais je n'ai pas de faits réels pour le sauvegarder." Je ne sais pas ce qu'il entend par "expressif" donc je ne peux pas vraiment en parler ...
c'est tout XML standard (SOAP, WSDL, UDDI) - et sera donc plus facile à consommer
C'est manifestement faux. SOAP peut être capricieux, surtout lorsque vous entrez dans des choses comme les types complexes et les en-têtes d'authentification. Cela est particulièrement vrai lorsque vous commencez à faire des communications multilingues - obtenir PHP = consommer correctement et communiquer avec un .NET SOAP service qui utilisait des types complexes et l'authentification était un exercice d'horreur à clavier qui me fait me réveiller dans une sueur froide à ce jour. = REST est certainement plus facile à consommer - vous fournissez simplement l'URL et c'est fait! Vous avez vos données! Il y a quelques inconvénients à cela, selon vos besoins, mais pour de nombreux services Web, tout cela est nécessaire.
bien standardisé que REST
Il est "standardisé" par le fait qu'il a un schéma. C'est ça. En plus de cela, vous encore allez devoir travailler avec les données de quelqu'un d'autre, qui n'est jamais un pique-nique, quel que soit le protocole de communication que vous utilisez. Et REST a un standard - son appelé HTTP . Il fonctionne plutôt bien.
Google utilise beaucoup de SOAP
Ils utilisé pour utiliser SOAP (ils peuvent encore pour certains produits, mais pas beaucoup). La majorité de leurs services Web sont solidement basés sur REST. Voici un lien montrant que ils ont abandonné un service SOAP en faveur de REST.
il est important de respecter les normes SOAP que de créer un schéma XML personnalisé dans REST
Cela ressemble à l'un de ces commentaires faits par des supérieurs avec une compréhension limitée de la technologie actuelle. Il n'y aura qu'une partie du paquet SOAP qui est normalisé - l'en-tête du message et l'encapsuleur. Tout le reste est votre propre XML. Vous devez toujours créer votre propre message. Le le message lui-même n'est pas conforme à une norme spécifique. Il s'agit toujours d'un objet sérialisé ou d'un groupe d'objets.
En guise de conclusion, SOAP versus REST est un gros sujet, sans réponse concrète et vous obtiendrez probablement des réponses différentes selon la personne à qui vous parlez) . En fait, je ne peux pas dire avec certitude que dans votre cas particulier cela REST [~ # ~] sera [~ # ~] mieux mais je peux dire que les arguments de vos patrons sont faibles et indiquent un manque de compréhension de la distinction entre les deux . J'ai utilisé les deux technologies et ma conclusion dure et rapide est la suivante: il n'y a pas de conclusion dure et rapide et, comme tant d'autres décisions technologiques, cela dépend des besoins de l'organisation. La meilleure solution, vraiment, est une recherche réfléchie, une discussion ouverte entre les personnes travaillant sur le projet pour trouver la meilleure solution, et un regard honnête sur vos besoins.
Voici quelques liens vers des discussions existantes qui peuvent être bénéfiques.
SAVON ou REPOS? D'autres réponses vous aident à faire valoir ce point d'un point de vue technique. Cependant, je prédis qu'un KO est peu probable simplement parce que techniquement, vous pouvez faire la plupart des choses avec l'une ou l'autre approche. Il y a quelques exceptions qui peuvent entraîner un KO technique, par exemple:
- si les demandes d'API doivent être routables via un middleware de messagerie externe tout en permettant au destinataire d'authentifier et de vérifier l'expéditeur d'origine, alors [SOAP gagne
- si vous voulez utiliser l'authentification et la logique de contrôle d'accès de votre application existante, alors REST peut être virtuellement un NOP, tandis que pour SOAP qui peut être un mini-projet à part entière.
Si vous n'avez pas une de ces exigences exceptionnelles comme un must-have, et puisque vous n'êtes pas le patron (!), Je pense que le mieux que vous puissiez espérer est un match nul car même si la décision semble "technique" elle restera subjectif.
Mais .. si vous voulez prendre la meilleure décision (et pas seulement gagner un argument), vous pouvez peut-être pousser à regarder cela, avec votre patron, d'une manière différente:
Puisque vous "devez créer une API pour notre système", je déduis que ce n'est pas seulement un détail technique interne de votre système et que "les arguments techniques sont pour les techniciens - alias les personnes qui feront le travail" ne fait pas '' t appliquer. Il y a un groupe de personnes quelque part qui devra s'occuper de tout ce que vous livrez, et je pense que vous aimeriez probablement qu'ils l'utilisent et l'adorent? Si c'est le cas:
Ce dont ils ont besoin pour l'API l'emporte probablement sur tous les arguments que vous ou votre patron pouvez trouver (du moins c'est ce qu'ils penseraient)
par exemple. s'ils veulent s'intégrer à votre API via BizTalk ou quelque chose comme ça, alors peut-être SOAP c'est le cas (document littéral et tout). Mais s'il s'agit de codeurs qui écriront sur votre API, SOAP peut être le glas de l'adoption, tandis que REST fera de vous des héros.
Si vous savez déjà qui sont ces personnes, je pense que vous devriez leur demander ce dont elles ont besoin d'une API. S'il s'agit d'un "nouveau marché", essayez peut-être de trouver les meilleurs représentants que vous pouvez trouver, ou du moins de décrire et de comprendre ce que sera "l'environnement client représentatif" pour éclairer la décision.
En d'autres termes, je vous recommande de voir si vous pouvez trouver le voix du client auprès de vrais clients externes ou d'autres membres de l'organisation ou partenaires qui peuvent faire un bon travail de pré-lancement intérimaire.
(puis quand ils vous disent "REPOS! N'osez-vous pas nous donner un peu de Rube Goldberg SOAP monstruosité", vous pouvez sourire en connaissance de cause à votre patron)
C'est un processus en deux étapes:
Convainquez votre patron que c'est l'équipe technique qui doit choisir la direction technique et non la gestion.
Choisissez REST. Ou du savon. Ou POX. Ou peu importe.
Les arguments techniques sont pour les techniciens - c'est-à-dire les personnes qui feront le travail. Une fois que le patron commence à décider de la technologie, vous avez un problème social. Vous devez convaincre votre patron de retirer ses mains du gâteau et de vous laisser faire votre travail.
Je proposerais un test: coder deux solutions qui font le même service très simple. Utilisez SOAP et une API REST-ful et comparez les résultats. Étant donné les ensembles d'outils d'aujourd'hui, il ne devrait pas y avoir beaucoup de différence. Vous pouvez tenir un service assez facilement.
Modifiez ensuite l'API. D'après mon expérience, un développeur qui modifie une API REST peut facilement apporter les modifications car il s'agit d'un protocole conceptuel qu'il comprend. D'après mon expérience, le SOAP L'API s'appuiera sur l'outillage pour accomplir n'importe quoi. Vous pouvez le faire à la main mais très peu de gens le font (pour des raisons évidentes) une fois que vous voyez le code/le balisage généré.
Mieux encore ... demandez à votre patron de faire l'implémentation SOAP.
Vous devriez regarder les différents environnements, où votre système est utilisé et si ces environnements effectuent la communication inter-système principalement de manière reposante, votre système devrait également offrir une telle interface. (Cela signifie que si vos clients l'utilisent, votre système devrait également le faire.)
Au lieu d'entrer dans les arguments perpétuels patron vs codeur, prenons quelques cas spécifiques et évaluons la pertinence du modèle. REST les amoureux sont les bienvenus pour réfuter avec des arguments logiques et basés sur des faits -
Objectif: accès à distance aux services/suppression des restrictions du pare-feu/liaison avec des protocoles tels que HTTP
Options: SOAP/REST (rejet des protocoles comme RMI etc. car c'est un peu hors contexte)
cas d'utilisation 1: J'ai besoin d'une liaison optimisée (JMS/RMI) pour plusieurs raisons telles que a) la propagation du contexte de transaction b) un échange de grande charge utile c) une qualité de service stricte Ici, mon choix sera SOAP. J'ai vu quelqu'un mentionner des problèmes d'interopérabilité avec des types complexes - veuillez expliquer pourquoi pensez-vous que la conformité du profil de base WS-I ne peut pas résoudre votre problème (avec un exemple de préférence).
cas d'utilisation 2: j'ai besoin d'une propagation d'identité (assertion) dans un environnement fédéré d'intermédiaires de confiance (actifs ou passifs). Il s'agit d'un cas d'utilisation B2B. Je ne pense pas avoir une manière définie d'attacher une politique avec un point de terminaison REST. Par conséquent SOAP devient le choix évident)
cas d'utilisation 3: j'ai besoin d'une API de gestion pour mon PaaS. Les mbeans JMX doivent être exposés en tant que services. C'est une sorte de point à point dans la nature. La bande passante est une contrainte. La gouvernance n'est pas une préoccupation. Le client basé sur un navigateur le rend plus utilisable. HTTPS est assez bon dans ce cas, je ne vais pas avoir à me soucier de la sécurité au niveau des messages. Je vais choisir REST car je n'ai pas besoin des subtilités et de la complexité de SOAP dans ce cas particulier).
cas d'utilisation 4: j'ai besoin d'un support de messagerie fiable. WS-RM peut résoudre ce problème. SOAP est le modèle évident ici car le SOAP moteur/serveur d'applications a OOTB support pour la configuration WS-RM).
cas d'utilisation 5: J'ai besoin d'invoquer plusieurs points de terminaison dans un contexte TX et HTTP est la seule option disponible pour le protocole de transport. Je ne pense pas que REST supporte WS-AT donc je vais avec SOAP
cas d'utilisation 6: J'ai besoin d'un point de terminaison asynchrone. Je ne veux pas retarder inutilement le thread demandeur. SOAP sera le choix.
cas d'utilisation 7: Je veux supprimer le surcoût inutile de la conversion de XML en types car les données arriveront de toute façon sur une interface utilisateur avec une transformation minimale ou nulle. REST avec JSON serait mon choix.
En général, si je pense à des DONNÉES/RESSOURCES, je préférerais REST si je pense à des opérations/méthodes (sync/async .. state..message level security..scalability) I être enclin à utiliser SOAP
Permettez-moi de ne pas apporter la gouvernance et SOA angle ici. Je ne vais pas vouloir sonner comme "one-of-those" dans un forum dédié aux développeurs.
N'hésitez pas à me corriger sur ce qui précède ..
L'un des avantages importants de REST qui n'a pas été augmenté, est qu'il est cachable et facilement évolutif. SOAP n'est pas cachable, car c'est un POST demande.