Du savon ou du repos pour les services Web? [fermé]

Est RESTE la meilleure approche pour faire des Services Web ou de SAVON? Ou sont-ils différents outils pour différents problèmes? Ou est-ce un nuancée de la question est, est un peu mieux dans certains domaines que l'autre, etc?

Bounty-Edit:

maintenant, presque trois ans plus tard, je voudrais poser cette question à nouveau - offrant une prime pour encourager une réponse approfondie. J'apprécierais tout particulièrement des informations sur ces concepts et leur relation avec L'univers PHP et aussi des applications web haut de gamme modernes.

368
demandé sur hugomg 2008-09-17 00:26:17
la source

28 ответов

j'ai construit l'un des premiers serveurs SOAP, y compris la génération de code et la génération WSDL, à partir de la spécification d'origine pendant son développement, lorsque je travaillais chez Hewlett-Packard. Je ne recommande pas D'utiliser du savon pour quoi que ce soit.

l'acronyme" SOAP " est un mensonge. Elle n'est pas Simple, elle n'est pas orientée objet, elle ne définit pas de règles D'accès. C'est, sans doute, un Protocole. C'est le pire spec De Don Box, et c'est un exploit, car c'est lui qui a perpétré le "COM".

il n'y a rien d'utile dans SOAP qui ne puisse être fait avec REST pour le transport, et JSON, XML, ou même du texte simple pour la représentation des données. Pour la sécurité des transports, vous pouvez utiliser https. Pour l'authentification, authentification basique. Pour les sessions, il y a des cookies. La version REST sera plus simple, plus claire, plus rapide et utilisera moins de bande passante.

XML-RPC définit clairement les protocoles de requête, de réponse et d'erreur, et il existe de bonnes bibliothèques pour la plupart des langues. Cependant, XML est plus lourd que vous n'avez besoin pour de nombreuses tâches.

551
répondu mdhughes 2008-09-17 00:59:47
la source

reste est une architecture, SOAP est un protocole.

C'est le premier problème.

vous pouvez envoyer des enveloppes de savon dans une application de repos.

SOAP lui-même est en fait assez basique et simple, c'est les normes WSS - * sur elle qui la rendent très complexe.

si vos consommateurs sont d'autres applications et d'autres serveurs, Il ya beaucoup de soutien pour le protocole SOAP aujourd'hui, et les bases de déplacement data est essentiellement un clic de souris dans les IDEs modernes.

si vos consommateurs sont plus susceptibles d'être des clients RIAs ou Ajax, vous voudrez probablement quelque chose de plus simple que SOAP, et plus natif pour le client (notamment JSON).

les paquets JSON envoyés par HTTP ne sont pas nécessairement une architecture REST, ce sont juste des messages vers des URLs. Tout cela est parfaitement réalisable, mais il y a des éléments clés dans l'idiome REST. Il est facile de confondre les deux. Mais juste parce que vous êtes parler des requêtes HTTP ne signifie pas nécessairement que vous avez une architecture REST. Vous pouvez avoir une application REST sans HTTP du tout (mind, c'est rare).

donc, si vous avez des serveurs et des consommateurs qui sont" à l'aise " avec le savon, le savon et la pile WSS peuvent vous servir bien. Si vous faites plus de choses ad hoc et que vous voulez une meilleure interface avec les navigateurs web, alors un protocole plus léger sur HTTP peut aussi bien fonctionner.

193
répondu Will Hartung 2008-09-17 00:37:56
la source

le repos est un paradigme fondamentalement différent du savon. Une bonne lecture sur le repos peut être trouvé ici: comment j'ai expliqué le repos à ma femme .

si vous n'avez pas le temps de le lire, voici la version courte: le repos est un peu un changement de paradigme en se concentrant sur les" noms", et en limitant le nombre de" verbes " que vous pouvez appliquer à ces noms. La seule verbes sont "get", "", "post" et "supprimer". Cela diffère de SOAP où de nombreux verbes différents peuvent être appliqué à de nombreux noms différents (c.-à-d. de nombreuses fonctions différentes).

pour le reste, les quatre verbes correspondent aux requêtes HTTP correspondantes, tandis que les noms sont identifiés par des URLs. Cela rend la gestion de l'état beaucoup plus transparente que dans SOAP, où il est souvent difficile de savoir quel est l'état sur le serveur et ce qui est sur le client.

dans la pratique bien que la plupart de cela tombe loin, et le repos se réfère habituellement juste à des requêtes HTTP simples qui retournent des résultats dans JSON , alors que SOAP est une API plus complexe qui communique en passant XML. Tous les deux ont leurs avantages et inconvénients, mais j'ai constaté que, d'après mon expérience, le repos est généralement le meilleur choix parce que vous avez rarement, voire jamais besoin de la fonctionnalité complète que vous obtenez de SOAP.

101
répondu toluju 2013-05-15 17:53:57
la source

Quick vérité pour 2012 question:

les zones pour lesquelles le repos fonctionne vraiment bien sont:

  • bande passante et ressources limitées. rappelez - vous que la structure de retour est vraiment dans n'importe quel format (défini par le développeur). De plus, n'importe quel navigateur peut être utilisé parce que L'approche REST utilise les verbes standard GET, PUT, POST et DELETE. Encore une fois, rappelez-vous que REST peut également utiliser L'objet XMLHttpRequest que la plupart des les navigateurs prennent en charge aujourd'hui, ce qui ajoute un bonus supplémentaire D'AJAX.

  • opérations totalement apatrides. si une opération doit être poursuivie, le repos n'est pas la meilleure approche et le SOAP peut être mieux adapté. Cependant, si vous avez besoin d'opérations stateless CRUD (Create, Read, Update, and Delete), le reste est fait.

  • mise en Cache des situations. si l'information peut être cached en raison de l'opération totalement apatride de l'approche de repos, c'est parfait.Qui couvre beaucoup de solutions dans les trois ci-dessus.

alors pourquoi je prendrais même du savon? Encore une fois, SOAP est assez mature et bien défini et ne vient avec une spécification complète. L'approche de repos est juste cela, une approche et est largement ouvert pour le développement, Donc si vous avez la suivante, puis SOAP est une grande solution:

  • asynchrone processing and invocation. si votre application a besoin d'un niveau garanti de fiabilité et de sécurité, alors SOAP 1.2 offre des normes supplémentaires pour assurer ce type d'opération. Des choses comme WSRM-WS-messagerie fiable.

  • contrats Formels. si les deux parties (fournisseur et consommateur) doivent s'entendre sur le format d'échange, alors SOAP 1.2 donne les spécifications rigides pour ce type d'interaction.

  • opérations Dynamiques. si l'application nécessite des informations contextuelles et une gestion d'état conversationnel, alors SOAP 1.2 A la spécification supplémentaire dans la structure WS* pour supporter ces choses (sécurité, Transactions, Coordination, etc). Comparativement, l'approche de repos ferait les développeurs construire cette plomberie personnalisée.

http://www.infoq.com/articles/rest-soap-when-to-use-each

56
répondu PmanAce 2015-08-04 00:00:42
la source

SOAP a actuellement l'avantage de meilleurs outils où ils généreront une grande partie du code boilerplate pour la couche service ainsi que générer des clients à partir de n'importe quel WSDL donné.

REST est plus simple, peut être plus facile à maintenir en conséquence, se trouve au cœur de l'architecture Web, permet une meilleure visibilité du protocole, et a fait ses preuves à l'échelle de la taille du WWW lui-même. Quelques cadres là-bas vous aider à construire des services de repos, comme Ruby on Rails, et certains même vous aider à écrire des clients, comme ADO.NET services de données. Mais pour la plupart, outil de manque d'appui.

44
répondu Mark Cidade 2008-09-17 00:36:37
la source

le savon est utile du point de vue de l'outillage parce que la WSDL est si facilement consommée par les outils. Ainsi, vous pouvez obtenir des clients de service web générés pour vous dans votre langue préférée.

reste joue bien avec les pages web AJAX'Y. Si vous gardez vos demandes simples, vous pouvez faire des appels de service directement à partir de votre JavaScript, et c'est très pratique. Essayez de rester à l'écart d'avoir des espaces de noms dans votre réponse XML, j'ai vu les navigateurs étouffer sur ceux. Donc, xsi:type probablement ne va pas travailler pour vous, pas de schémas XML trop complexes.

repos tend à avoir une meilleure performance aussi bien. Les exigences CPU du code générant des réponses de repos ont tendance à être inférieures à ce que les cadres SOAP montrent. Et, si vous avez votre génération de ducks XML alignée du côté du serveur, vous pouvez efficacement diffuser XML vers le client. Imaginez que vous lisiez des lignes de curseur de la base de données. En lisant une rangée, vous la formatez comme un élément XML, et vous écrivez que directement au consommateur de services. De cette façon, vous n'avez pas à collecter toutes les lignes de la base de données en mémoire avant de commencer à écrire votre sortie XML - vous lisez et écrivez en même temps. Regardez dans de nouveaux moteurs de templating ou XSLT pour obtenir le streaming pour travailler pour le repos.

SOAP d'un autre côté a tendance à être généré par des services générés à l'aide d'outils comme un gros blob et seulement alors écrit. Ce n'est pas une vérité absolue, l'Esprit vous, Il ya des moyens d'obtenir streaming caractéristiques à partir de savon, comme en utilisant des attaches.

mon processus de prise de décision est le suivant: si je veux que mon service soit facilement utilisé par les consommateurs, et que les messages que j'écris soient de moyenne à petite taille (10 Mo ou moins), et que je n'ai pas d'objection à brûler quelques cycles CPU supplémentaires sur le serveur, je vais avec SOAP. Si j'ai besoin de servir à AJAX sur les navigateurs web, ou j'ai besoin de la chose à diffuser, ou mes réponses sont gigantesques, je vais me reposer.

enfin, il y a des lots de grands standards construits autour de SOAP, comme WS-Security et getting stateful Web Services, que vous pouvez brancher si vous utilisez les bons outils. Ce genre de choses fait vraiment une différence, et peut vous aider à satisfaire certaines exigences poilues.

40
répondu Tim Cooper 2011-09-29 20:09:36
la source

1) la mise en œuvre d'un service de repos prend infiniment plus de temps que la mise en œuvre d'un service SOAP. Des outils existent pour tous les langages/cadres/plates-formes modernes pour lire dans une WSDL et des classes de proxy de sortie et des clients. La mise en œuvre d'un service de repos se fait à la main et - obtenez ceci - en lisant la documentation. En outre, lors de la mise en œuvre de ces deux services, vous devez faire des "conjectures" sur ce qui va revenir à travers le tuyau car il n'y a pas de véritable schéma ou document de référence.

2) Pourquoi écrire un service de repos qui retourne XML de toute façon? La seule différence est qu'avec REST vous ne connaissez pas les types que chaque élément/attribut représente - Vous êtes sur votre propre pour l'implémenter et espérer qu'un jour une chaîne ne tombe pas dans un domaine que vous pensiez être toujours un int. SOAP définit la structure des données à l'aide de la WSDL, donc c'est une évidence.

3) j'ai entendu la plainte qu'avec le savon vous avez le "au-dessus" de l'enveloppe du savon. En cette journée et l' l'âge, n'avons-nous vraiment besoin de s'inquiéter une poignée d'octets?

4) j'ai entendu l'argument qu'avec le repos vous pouvez juste pop L'URL dans le navigateur et voir les données. Bien sûr, si votre service REST utilise une authentification simple ou pas. Le service Netflix, par exemple, utilise OAuth qui vous demande de signer des choses et d'encoder des choses avant même de pouvoir soumettre votre demande.

5) Pourquoi avons-nous besoin d'une URL "lisible" pour chaque ressource? Si nous utilisions un outil pour mettre en œuvre le service, ne nous soucions vraiment de l'URL?

dois-je continuer?

29
répondu Josh M. 2010-07-24 01:19:18
la source

la plupart des applications que j'écris sont C# ou Java côté serveur, ou des applications bureau dans WinForms ou WPF. Ces applications ont tendance à avoir besoin d'une API de service plus riche que REST peut fournir. De plus, Je ne veux pas passer plus de quelques minutes à créer mon client de service web. Les outils de génération de clients de traitement WSDL me permettent de mettre en œuvre mon client et de passer à la valeur ajoutée.

maintenant, si j'écrivais un service web explicitement pour un certain javascript ajax appelle, il serait probablement dans le repos; juste pour le plaisir de connaître la technologie du client et de tirer parti de JSON. À mon avis, les API de service web utilisées à partir de javascript ne devraient probablement pas être très complexes, car ce type de complexité semble être mieux gérée côté serveur.

cela dit, il y a des clients SOAP pour javascript; je sais que jQuery en a un. Ainsi, SOAP peut être tiré de javascript; tout simplement pas aussi bien qu'un service de repos retour JSON chaîne. Donc, si j'avais un service web que je voulais être assez complexe pour qu'il soit flexible pour un nombre arbitraire de technologies client et d'utilisations, J'irais avec SOAP.

19
répondu Travis Heseman 2009-09-22 19:36:38
la source

je vous recommande D'aller avec le repos d'abord - si vous utilisez Java, regardez JAX-RS et l'implémentation Jersey . REST est beaucoup plus simple et facile à interop dans de nombreuses langues.

comme d'autres l'ont dit dans ce fil, le problème avec SOAP est sa complexité lorsque les autres spécifications WS-* viennent et il y a d'innombrables questions interop si vous vous égarez dans les mauvaises parties de WSDL, XSDs, SOAP, WS-Addressing etc.

le la meilleure façon de juger le reste V soap débat est de regarder sur l'internet - à peu près tous les grands acteurs de l'espace web, google, amazon, ebay, twitter et al - ont tendance à utiliser et préfèrent les API Reposful sur les SOAP ceux.

l'autre approche agréable pour aller avec le repos est que vous pouvez réutiliser beaucoup de code et d'infratucture entre une application web et un front end de repos. par exemple, rendre HTML versus XML versus JSON de vos ressources est normalement assez facile avec des cadres comme JAX-RS et vues implicites-plus son facile de travailler avec des ressources Reposful en utilisant un navigateur web

17
répondu James Strachan 2008-09-17 15:18:06
la source

je suis sûr de Ne Cocher créé SAVON comme une blague - " regardez-vous peut appel RPC méthodes sur le web " et aujourd'hui râle quand il se rend compte de ce qu'est un ballonnement cauchemar des standards du web, il est devenu :-)

RESTE est bon, simple, mis en œuvre partout (donc plus "standard" que les normes) rapide et facile. Le REPOS.

16
répondu gbjbaanb 2008-09-17 00:54:41
la source

je pense que les deux ont leur place. À mon avis:

SAVON de marseille : UN meilleur choix pour l'intégration entre héritage/critique des systèmes et web/web-service, sur la couche de fondation, où WS-* sens (sécurité, politique, etc.).

RESTful : un meilleur choix pour l'intégration entre les sites Web, avec API publique, sur le dessus de la couche (voir, c'est à dire, javascripts prendre des appels à URIs).

15
répondu irobson 2015-11-18 23:50:44
la source

une chose qui n'a pas été mentionnée est qu'une enveloppe de savon peut contenir des en-têtes ainsi que des parties du corps. Cela vous permet d'utiliser la pleine expressivité de XML pour envoyer et recevoir des informations hors bande. Le reste, pour autant que je sache, vous limite aux en-têtes HTTP et aux codes de résultat.

(otoh, que, pouvez-vous utiliser des cookies avec une RESTE le service pour envoyer des "en-tête"-taper les données de la bande?)

13
répondu John Saunders 2009-08-19 13:51:20
la source

répondant à la question rafraîchie de 2012 (par la deuxième prime), et en passant en revue les résultats d'aujourd'hui (autres réponses).


savon, pour et contre

à propos de SOAP 1.2, avantages et inconvénients en comparant avec "REST"... Eh bien, depuis 2007 vous pouvez décrire les services REST Web avec WSDL , et en utilisant le protocole SOAP... C'est-à-dire, si vous travaillez un peu plus dur, toutes les normes W3C de la pile de protocole de services web peut être le repos !

c'est un bon point de départ, car nous pouvons imaginer un scénario dans lequel toutes les discussions philosophiques et méthodologiques sont temporairement évitées. Nous pouvons comparer techniquement " SOAP-REST "avec" NON-SOAP-REST "dans des services similaires,

  • savon-repos (="repos-savon"): comme montré par L. Mandel , WSDL2 peut décrire un service web REST, et, si nous supposons que XML illustré peut être enveloppé dans SOAP, toute l'implémentation sera "SOAP-REST".

  • NON-SOAP-REST : tout service web REST qui ne peut pas être SOAP... C'est-à-dire," 90% " des exemples de repos bien connu. Certains n'utilisent pas le XML (p. ex. les silences AJAX typiques utilisent JSON à la place), certains utilisent une autre structure XML, sans les en-têtes ou les règles SOAP. PS: pour éviter l'informalité, nous pouvons supposons que reste niveau 2 dans les comparaisons.

bien sûr, pour comparer plus conceptuellement, comparez "Non-REST-SOAP" avec "NON-SOAP-REST", comme différentes approches de modélisation. Ainsi, l'obtention de ce taxonomie des services web:

  • Non-REST-SOAP : tout service Web SOAP qui ne peut pas être REST... C'est-à-dire" 90% " des exemples bien connus du SOAP.

  • NON-REST-NEITHER-SOAP : Oui, l'univers de la "modélisation de services web" comprend d'autres choses (ex. XML-RPC ).

savon dans les conditions de repos

Comparer des choses comparables: SOAP-REPOS avec NON-SOAP-REPOS .

PROS

En expliquant certains termes,

  • stabilité contractuelle : pour tous les types de contrats (en tant qu ' "accords écrits"),

    • Par le utilisation de la série : tous les niveaux de la W3C de la pile sont mutuellement compatibles. REST, par contre, n'est pas une norme W3C ou ISO et n'a pas de détails normalisés sur les périphériques du service. Donc, comme je , @DaveWoldrich(20 votes), @cynicalman(5), @Exitos(0) dit avant, dans un contexte où sont BESOIN DE NORMES, vous avez besoin de SAVON.

    • Par le l'utilisation des meilleures pratiques : les "commentaires" de la W3C de la pile implémentations, traduit de l'homme applicables/juridique/juridique des accords.

  • Robustesse : la sécurité de la structure du savon et des en-têtes. Avec metada communication (avec la pleine expressivité de XML) et vérification vous avez une" police d'assurance " contre tout changement ou bruit.

    SAVON ont "transactionnelle de la fiabilité (...) traiter les problèmes de communication. SOAP a plus de contrôles autour de la logique de retry et peut donc fournir plus de fiabilité de bout en bout et des garanties de service", E. Terman .

tri des pros par popularité,

  • Better tools (~70 votes): le SOAP a actuellement l'avantage de meilleurs outils, depuis 2007 et encore 2012, car il s'agit d'une norme bien définie et largement acceptée. Voir @ MarkCidade(27 votes), @DaveWoldrich(20), @JoshM(13), @TravisHeseman (9).

  • conformité aux normes (25 votes): comme I , @DaveWoldrich(20 votes), @cynicalman(5), @Exitos (0) l'a déjà dit, dans un contexte où il faut des normes, il faut du savon.

  • Robustesse : assurance des en-têtes de savon, @JohnSaunders (8 votes).

CONS

  • la structure du savon est plus complexe (plus de 300 votes): toutes les réponses ici, et les sources sur" SOAP vs REST", manifestent une certaine aversion pour la redondance et la complexité de SOAP. Il s'agit d'une conséquence naturelle des exigences de vérification formelle (voir ci-dessous), et de robustesse (voir ci-dessus). "REST NON-SOAP "(et XML-RPC, le soap originator ) peut être plus simple et informel.

  • la restriction "only XML" est un obstacle à la performance lorsqu'on utilise de petits services (~50 votes): voir json.org/xml et cette question , ou cette autre question . Ce point est montré par @toluju (41), et d'autres.

    PS: comme JSON n'est pas une norme IETF , mais nous pouvons considérer un norme de fait pour les logiciels web communauté.


services de modelage avec savon

maintenant, nous pouvons ajouter SOAP-NON-REST avec Non-SOAP-REST comparaisons, et expliquer quand il est préférable d'utiliser du savon :

  • besoin de normes et de contrats stables (voir la section "pour"). PS: voir a type" B2B besoin de normes "décrit par @saille .

  • besoin d'outils (voir la section "pour"). PS: normes , et l'existence de vérifications formelles (voir ci-dessous), sont des questions importantes pour les outils d'automatisation.

  • traitement lourd en parallèle (voir "Context / Foundations" section ci-dessous): avec des processus plus grands et/ou plus lents, peu importe avec un peu plus de complexité de savon, la fiabilité et la stabilité sont les meilleurs investissements.

  • besoin de plus de sécurité : quand plus de HTTPS est nécessaire, et que vous avez vraiment besoin de fonctionnalités supplémentaires pour la protection, SOAP est un meilleur choix ( voir @Bell , 32 votes). "Envoyer le message sur un chemin plus compliqué que requête/réponse ou au cours d'un transport qui n'implique pas HTTP", S. Seely . XML est une question centrale, offrant des normes pour XML Encryption , XML Signature , et XML Canonisation , et, seulement avec SOAP vous pouvez intégrer ces mécanismes dans un message par une norme bien acceptée comme WS-Security .

  • Besoin de plus de flexibilité (moins de restrictions): SOAP n'a pas besoin de correspondance exacte avec un URI; pas de Ned se limiter à HTTP; pas besoin de se limiter à 4 verbes. Comme @TravisHeseman (9 votes) le dit, si vous vouliez quelque chose de "flexible pour un nombre arbitraire de technologies et d'utilisations client", utilisez du savon.

    PS: rappelez-vous que le XML est plus universel/expressif que JSON (et al.).

  • besoin de formel vérifications : important pour comprendre que W3C cheminée utilise méthodes formelles , et le repos est plus informel. Votre description de service WSDL (a formal language ) est une spécification formelle de vos interfaces de services web, et SOAP est un protocole robuste qui accepte toutes les prescriptions WSDL possibles.

contexte

historique

Pour évaluer les tendances est nécessaire perspective historique. Pour ce sujet, une perspective de 10 ou 15 ans...

avant la standardisation W3C, il y a une certaine anarchie. Il était difficile de mettre en œuvre des services interopérables avec différents cadres, et plus difficile, coûteux et fastidieux à mettre en œuvre quelque chose d'interopérable entre les entreprises. Les normes W3C stack ont été la lumière, un nord pour l'interopérabilité des séries de complexes de services web.

pour les tâches quotidiennes, comme mettre en œuvre AJAX, SOAP est lourd... Ainsi, le besoin d'approches simples doit choisir une nouvelle théorie-cadre... Et de grands "lecteurs de logiciels Web", comme Google, Amazon, Yahoo, et autres, ont choisi la meilleure alternative, qui est l'approche du repos. Était dans ce contexte que le concept de repos est arrivé comme un "cadre concurrentiel", et, aujourd'hui (2012's), cette alternative est un de facto norme pour les programmeurs.

fondations

dans un contexte de Parallel Computing les services web fournit des sous-tâches parallèles; et les protocoles, comme SOAP, assure une bonne synchronisation et la communication. Pas "n'importe quelle tâche": les services web peuvent être classés comme

parallélisme grossier et embarrassant .

comme la tâche devient plus grande, il devient moins significatif "débat de complexité", et devient plus pertinent la robustesse de la communication et la solidité des contrats.

10
répondu Peter Krauss 2017-05-23 15:26:36
la source

c'est nuancé.

si vous avez besoin d'avoir d'autres interfaces systèmes avec vos services, que beaucoup de clients seront heureux avec SOAP, en raison des couches de" vérification " que vous avez avec les contrats, WSDL, et la norme SOAP.

pour les systèmes quotidiens appelant dans les systèmes, Je pense que SOAP est beaucoup de frais généraux inutiles quand un simple appel HTML fera l'affaire.

9
répondu cynicalman 2008-09-17 00:28:22
la source

N'oubliez pas XML-RPC. Si vous êtes juste après une solution légère, alors il ya beaucoup à dire pour un protocole qui peut être défini dans quelques pages de texte et mis en œuvre dans une quantité minimale de code. XML-RPC existe depuis des années, mais il est devenu désuet depuis un certain temps - mais l'attrait minimaliste semble lui donner une sorte de renaissance de ces derniers temps.

9
répondu Cruachan 2008-09-17 00:34:58
la source

je regarde la même chose, et je pense, ils sont des outils différents pour des problèmes différents .

Simple Object Access Protocol (SOAP) standard d'un langage XML de la définition d'une architecture de message et les formats de message, est utilisé par les services Web, il contient une description des opérations. WSDL est un langage XML pour décrire les services Web et comment y accéder. sera exécuté sur le serveur SMTP,HTTP,FTP, etc. Nécessite un support middleware, bien défini mechanisam pour définir des services comme WSDL+XSD, WS-Policy SOAP retournera des données basées sur XML SOAP fournir des normes pour la sécurité et la fiabilité

Representational State Transfer (RESTful) web services. il s'agit de Services Web de deuxième génération. Les services web RESTful communiquent via HTTP que les services SOAP et ne nécessitent pas de messages XML ou de définitions WSDL service-API. pour le repos, aucun middleware N'est requis, seul le support HTTP est nécessaire.WADL Standard, REST peut renvoyer XML, plain text, JSON, HTML etc

il est plus facile pour de nombreux types de clients de consommer des services web reposant tout en permettant au côté serveur d'évoluer et de se dimensionner. Les Clients peuvent choisir de consommer certains ou tous les aspects du service et réduire en purée avec d'autres services web.

  1. REST utilise le HTTP standard pour créer des clients, développer des API
  2. reste permet de nombreux formats de données différents comme XML, texte simple, JSON, HTML Où as SOAP ne permet que le XML.
  3. repos a une meilleure performance et évolutivité.
  4. repos et peut être mis en cache et le savon ne peut pas
  5. traitement des erreurs intégré là où le savon n'a pas de traitement des erreurs
  6. reste est particulièrement utile PDA et autres appareils mobiles.

les autres services sont faciles à intégrer aux sites Web existants.

savon a ensemble de protocoles, qui fournissent des normes de sécurité et de fiabilité, entre autres choses, et d'interopérer avec d'autres clients et serveurs conformes WS. Les services web SOAP (tels que JAX-WS) sont utiles pour traiter le traitement asynchrone et l'invocation.

pour le savon complexe API sera plus utile.

9
répondu kapil das 2017-03-16 19:48:31
la source

REST est une architecture inventée par Roy Fielding et décrite dans sa thèse Architectural Styles and the Design of Network-based Software Architectures . Roy est également l'auteur principal de HTTP - le protocole qui définit le transfert de document sur le World Wide Web. HTTP est un protocole reposant. Lorsque les développeurs parlent d '"utiliser les services REST Web", il est probablement plus juste de dire " utiliser HTTP."

savon est un protocole basé sur le XML qui creuse un tunnel à l'intérieur D'une requête/réponse HTTP, donc même si vous utilisez SOAP, vous utilisez REST aussi. Il y a un certain débat sur la question de savoir si SOAP ajoute des fonctionnalités significatives au HTTP de base.

avant de créer un service Web, Je recommande D'étudier HTTP. Il est probable que vos exigences puissent être implémentées avec des fonctionnalités déjà définies dans le spec, donc d'autres protocoles ne seront pas nécessaires.

8
répondu Chris Broski 2011-08-17 03:03:56
la source

je regarde la même question. Il me semble que se reposer est en fait rapide et facile et bon pour les appels légers et les réponses et idéal pour le débogage (ce qui pourrait être mieux que de pomper une URL dans un navigateur et de voir la réponse).

cependant, où le reste semble tomber est lié au fait que ce n'est pas une norme (bien qu'elle se compose de normes). La plupart des bibliothèques de programmation ont un moyen d'inspecter un WSDL pour générer automatiquement le client code nécessaire pour consommer des services à base de savon. Jusqu'à présent, la consommation de services web reposant sur le repos semble une approche plus adhoc de l'écriture d'une interface pour correspondre aux appels qui sont possibles. Faire une requête http manuelle puis analyser la réponse. Cela peut en soi être dangereux.

la beauté de SOAP est qu'une fois qu'une WSDL est émise, les entreprises peuvent structurer leur aorund logique qui définit le contrat toute modification à l'interface va changer la wsdl. Il n'y a pas d'aucune marge de manoeuvre. Vous peut valider toutes les requêtes par rapport à cette WSDL. Cependant, parce qu'un WSDL ne décrit pas correctement un service de repos, vous n'avez aucune façon définie de vous mettre d'accord sur l'interface de communication.

d'un point de vue commercial, cela semble laisser la communication ouverte à l'interprétation et au changement, ce qui semble être une mauvaise idée.

la "réponse" supérieure dans ce fil semble dire que SOAP signifie Simple Object-oriented protocole D'accès, cependant en regardant wiki le O signifie objet non orienté objet. Ce sont des choses différentes.

je sais que ce post est très vieux, mais j'ai pensé que je devrais répondre avec mes propres conclusions.

7
répondu Exitos 2011-06-17 21:16:17
la source

c'est une bonne question... Je ne veux pas vous égarer, donc je suis ouverte à d'autres réponses autant que vous êtes. Pour moi, il s'agit vraiment de frais généraux et de l'utilisation de l'API est. Je préfère consommer des services web lors de la création de logiciel client, mais je n'aime pas le poids de SOAP. Le repos, je crois, est un poids plus léger, mais je n'aime pas travailler avec lui du point de vue du client presque autant.

je suis curieux de savoir ce que les autres pensent.

6
répondu cranley 2008-09-17 00:29:16
la source

Écouter ce podcast pour le savoir. Si vous voulez connaître la réponse sans écouter, alors D'accord, son reste. Mais je ne les recommande l'écoute.

6
répondu Mark Beckwith 2011-08-07 08:05:21
la source

ma règle générale est que si vous voulez qu'un navigateur Web client se connecter directement à un service, alors vous devriez probablement utiliser REST. Si vous souhaitez transmettre des données structurées entre des services de back-end, utilisez SOAP.

SOAP peut être une vraie douleur à mettre en place parfois et est souvent exagérée pour les échanges de données simple client web et serveur. Malheureusement, la plupart des exemples de programmation simples que j'ai vus (et appris de) quelque peu renforcer cette perception.

Cela dit, SOAP brille vraiment lorsque vous commencez à combiner plusieurs services SOAP ensemble dans le cadre d'un processus plus vaste piloté par un flux de données (pensez logiciel d'entreprise). C'est quelque chose que beaucoup des exemples de programmation SOAP ne parviennent pas à transmettre parce qu'une simple opération SOAP pour faire quelque chose, comme aller chercher le prix d'une action, est généralement sur-complicated pour ce qu'elle fait par elle-même à moins qu'elle ne soit présentée dans le contexte de fournir une API lisible par machine détaillant des fonctions spécifiques avec set les formats de données pour les entrées et les sorties qui sont, à leur tour, scénarisées par un processus plus vaste.

c'est triste, d'une certaine manière, car cela donne vraiment au savon une mauvaise réputation parce qu'il est difficile de montrer les avantages du savon sans le présenter dans le contexte complet de la façon dont le produit final est utilisé.

6
répondu Rick Sarvas 2013-05-15 19:33:36
la source

SOAP incarne une approche axée sur le service aux services Web-une approche dans laquelle les méthodes (ou verbes) sont la principale façon dont vous interagissez avec le service. REST adopte une approche axée sur les ressources dans laquelle l'objet (ou le nom) prend le devant de la scène.

4
répondu Vibha Sanskrityayan 2013-01-07 11:00:42
la source

dans le sens avec" PHP-univers " le soutien de PHP pour n'importe quel SOAP avancé craint grand temps. Vous allez finir par utiliser quelque chose comme http://wso2.com/products/web-services-framework/php / dès que vous traversez les besoins de base, même pour activer WS-Security ou WS-RM pas de support intégré.

la création de l'enveloppe SOAP je me sens beaucoup de désordre en PHP, la façon dont il crée des espaces de noms, xsd: nil, xsd: anytype et de vieux soap Services qui utilisent L'encodage SOAP (Dieu sait en quoi est-ce différent) avec dans les messages SOAP.

éviter tout ce désordre en restant au repos, le repos n'est pas grand nous l'avons utilisé depuis le début de WWW. Nous ne l'avons réalisé que lorsque ce http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm papier est sorti il montre comment pouvons-nous utiliser les capacités HTTP pour mettre en œuvre des Services RESTFul. HTTP est intrinsèquement repos, cela ne signifie pas que L'utilisation de HTTP rend vos services repos.

SOAP néglige les fonctionnalités de base de HTTP et considère HTTP comme un protocole de transport, il est donc indépendant du protocole de transport en théorie (en pratique, ce n'est pas le cas, Avez-vous entendu parler de SOAP action header? si ce n'est pas google maintenant!).

avec adaptation JSON croissante et HTML5 avec javascript maturité repos avec JSON est devenu le moyen le plus commun de traiter les services. JSON schéma a également été défini peut être utilisé pour des solutions au niveau de l'entreprise (encore à un stade précoce) ainsi que WADL si nécessaire.

le support PHP pour REST et JSON est certainement meilleur que le support SOAP existant.

l'Ajout de quelques mots à la mode ici, SOA, l'AMO, le ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

par la façon dont j'aime SOAP en particulier pour le WS-Security spec, il s'agit d'une bonne spec et si quelqu'un qui pense à L'entreprise JSON adaptation definetly besoin de venir avec quelque chose de similaire pour JSON, comme le cryptage au niveau du terrain, etc

4
répondu shivaspk 2013-02-26 21:09:07
la source

Un point rapide - protocole de transmission et d'orchestration;

j'utilise SOAP over TCP pour des raisons de vitesse, de fiabilité et de sécurité, y compris les services Machine à machine orchestrés (ESB) et aux services externes. Changer la définition de service, l'orchestration soulève une erreur du changement WSDL et son immédiatement évident et peut être reconstruit/déployé.

pas sûr que vous pouvez faire la même chose avec le repos - j'attends d'être corrigé ou sûr! Avec le repos, changer la définition de service-rien ne sait à ce sujet jusqu'à ce qu'il retourne 400 (ou peu importe).

3
répondu BlueChippy 2013-11-12 15:55:51
la source

si vous êtes à la recherche de l'interopérabilité entre différents systèmes et différentes langues, j'irais certainement me reposer. J'ai eu beaucoup de problèmes en essayant de faire fonctionner SOAP entre .NET et Java, par exemple.

2
répondu neu242 2008-09-17 00:34:18
la source

je crée un benchmark pour trouver lequel d'entre eux sont plus rapides! je vois ce résultat:

pour 1000 demandes:

  • repos de 3 secondes
  • SOAP taken 7 second

de 10 000 demandes :

  • le repos a pris 33 seconde
  • SAVON a eu 69 deuxième

pour 1 000 000 de demandes:

  • RESTE 62 deuxième
  • SOAP take 114 second
2
répondu Sonador 2016-01-23 14:58:53
la source

une vieille question mais toujours pertinente aujourd'hui....parce que de nombreux développeurs dans l'espace enterprise encore de l'utiliser.

mon travail consiste à concevoir et à développer des solutions Internet des objets (IoT). Ce qui inclut le développement de code pour les petits appareils embarqués qui communiquent avec le nuage.

il est clair que REST est maintenant largement accepté et utile, et à peu près la norme de facto pour le web, même Microsoft a le support REST inclus tout au long de Azure. Si j'avais besoin de compter sur SOAP, Je ne pouvais pas faire ce que j'avais à faire, comme c'est juste trop gros, encombrant et ennuyeux pour les petits appareils embarqués.

repos est simple et propre et petit. Idéal pour les petits appareils embarqués. Je crie toujours quand je travaille avec un développeur web qui m'envoie un WSDLs. Comme je vais devoir commencer une campagne d'éducation sur pourquoi cela ne va tout simplement pas fonctionner et pourquoi ils vont avoir à apprendre le repos.

0
répondu Remixed123 2015-03-12 05:53:10
la source

1.De mon expérience. Je dirais que REST vous donne la possibilité d'accéder à L'URL qui est déjà construite. eg - > une recherche de mots dans google. Cette URL peut être utilisée comme service web pour le repos. Dans SOAP, vous pouvez créer votre propre service web et y accéder via le client SOAP.

  1. reste supporte le texte,JSON,format XML. Donc plus polyvalent pour communiquer entre deux applications. Tandis que SOAP supporte uniquement le format XML pour la communication de messages.
0
répondu Shalini Baranwal 2015-09-30 10:01:47
la source

Autres questions sur xml rest soap web-services