Service Web vs application Web
Je sais que c’est une vieille question à laquelle il a déjà fallu répondre cent fois, mais je ne suis pas encore en mesure de trouver une réponse satisfaisante.
Je crée une application qui sera utilisée par d'autres applications (mobile/Web) pour récupérer les données. Maintenant, j'ai 2 options:
- Créer mon application comme une simple application web.
- Créez un service Web.
Un service Web semble plus sophistiqué lorsqu'un client fournira les données dans un format spécifié (SOAP/REST) et que mon application analysera la demande et renverra les données demandées par le client. La manière dont les données seront utilisées n'est pas le problème de mon application.
Ma question est la même chose peut être atteint par une simple application web acceptant la demande au format XML et répondant avec une réponse XML. Nous pensons qu'un service Web constituera un meilleur moyen d’utiliser ce type de service si nous ne savons pas qui l’utilisera. Mais y a-t-il des avantages spécifiques à utiliser un service Web par rapport à une application Web simple?
À un niveau bas, les applications Web et les services Web sont un peu la même chose. Ils opèrent tous deux sur http (s). SOAP est simplement une version bien définie de XML. REST est un peu HTTP. Si vous le souhaitez, vous pouvez faire en sorte qu'une application Web ressemble à des services Web et inversement.
La principale différence serait les options de développement interne basées sur la plate-forme que vous utilisez. Si, par exemple, vous utilisez Visual Studio, l'ajout d'une application de service WCF vous donnera un projet orienté par défaut vers WCF. Mais choisir un autre type d'application ne vous empêchera pas d'ajouter des services Web.
L'utilisation de SOAP est généralement une meilleure option que le vieux xml brut pour ces raisons:
Vos utilisateurs l'attendront et sauront probablement déjà le lire.
Les environnements de développement de vos utilisateurs sauront probablement tout sur SOAP et pourront l’interpréter dès le départ. (Si vous fournissez un fichier WSDL, de nombreux utilisateurs pourront utiliser un script pour générer vos classes en quelques secondes.)
Vos messages sont plus susceptibles d'être bien définis. Je travaille sur un projet en ce moment où l'autre partie a défini sa propre structure XML aléatoire et c'est un cauchemar. Je ne sais jamais vraiment à quoi m'attendre, et il y a peu de cohérence entre leurs différents types de messages. Du moins s’ils avaient accepté de se conformer à SOAP, j’aurais peut-être eu beaucoup plus de facilité à interpréter leurs messages.
Si nous pensons à la terminologie, je pense que la question principale est ici.
Service Web fait référence à un logiciel, qui sert des données dans n'importe quel format (XML/JSON, etc.) via une sorte d'interface Web. Cette interface peut être appelée API (Application Programming Interface). REST et SOAP permettent de concevoir l'API.
Application est le logiciel qui utilise cette API fournie par le service Web.
En d'autres termes, le service Web est "serveur" et l'application est "client". Généralement, le serveur dessert les machines et les clients servent l’utilisateur.
Ainsi, quelle que soit la méthode choisie pour construire votre système, j'appellerais la partie qui sert les données comme "service Web" et la partie qui utilise les données comme "application" (ou "application Web", le cas échéant).
Cela ressemble à votre cas, vous construisez un service Web qui fournit des données au format XML pour plusieurs applications. Donc, ma réponse est: construisez ce que vous construisez déjà et appelez-le service web .
Si votre application n'a pas besoin d'interface utilisateur, faites-en un service Web. S'il a besoin d'une interface utilisateur, utilisez une application Web.
Je pense que cela pourrait vous aider à résoudre votre confusion
Il y a deux principaux cas d'utilisation de WEB dans l'industrie
- Business to Consumer (B2C): chaque fois qu'il y a un consommateur qui interagit directement avec l'entreprise pour ses besoins, nous utilisons toujours une application Web Pour fournir une communication entre deux parties.
- Business to Business (B2B): Cela signifie qu’une partie du besoin de l’entreprise dépend de certains intrants/services d’une autre partie de l’entreprise. Toujours un Web-Service est utilisé pour répondre aux exigences commerciales des entreprises . En général, un consommateur n'interagit jamais directement avec les Web-Services. Nous n'interagissons qu'avec une Web-Application et une Web-Application avec un Web-Services pour les informations/données ou le traitement.
Extrait de http://coder2design.com/Java-interview-questions/
Ma question est la même chose peut être atteint par une simple application web acceptant la demande au format XML et répondant avec une réponse XML.
C'est un service Web. Je pense que c'est une question de terminologie. Vous n'avez pas d'autre moyen de résoudre ce problème que d'utiliser un service Web, qu'il soit reposant ou basé sur SOAP, cela dépend de vous, mais si vous transmettez des données à des clients au format XML, en réponse à des requêtes XML, c'est: un service web.
Je suppose que ce que vous voulez demander est de savoir si vous devriez ou non utiliser un service Web RESTful ou une approche compliquée basée sur SOAP. Pour moi, la réponse dépend du nombre de fonctions nécessaires dans votre «service».
SAVON
Si votre service comporte un grand nombre de fonctions que les utilisateurs de Java et/ou de visual studio préfèrent importer votre fichier WSDL et utiliser votre service en tant qu’objet avec l’ensemble de l’analyse XML effectuée, la réponse est donc SOAP .
DU REPOS
Si vous ne disposez que de quelques fonctions, avec des paramètres d'entrée et des données de réponse très élémentaires, il se peut que SOAP soit excessif.
MySite.com/Add/5/3
ou
MySite.com/GetStockSymbol/Facebook
ou
MySite.com/GetWeather/Paris/France
J'ai posé cette question il y a plus de trois ans et beaucoup d'eau a coulé sous le pont depuis lors. J'ai travaillé sur des dizaines d'applications Web et créé des centaines de services Web. Donc, je suppose qu'il est logique de répondre à ma propre question ici.
Le défi auquel j'ai été confronté lorsque j'ai posé cette question était que j'avais confondu les termes application et service (notez que le Web est un élément commun des applications et des services Web). Comme son nom l'indique, l'application est une application en soi, alors qu'un service est destiné à servir les autres. Un service n'a probablement de sens que si quelqu'un va l'utiliser. Il peut servir une ou plusieurs applications ou services.
Maintenant, si je regarde ma question
Je crée une application qui sera utilisée par d'autres applications (mobile/web) pour récupérer les données. Maintenant, j'ai 2 options, 1. créer mon application en tant qu'application Web simple 2. Pour créer un service Web.
Je voudrais me dire que "Mec! S'il y a une entité qui prend une demande et renvoie des données, vous parlez d'un service." Parce que je ne suis pas inquiet de ce qui va se passer avec ces données? Qui l'utilisera? Comment cela sera-t-il affiché?
Je prends une demande et retourne des données. Maintenant, comment je fais cela fait partie de la mise en œuvre. Je pourrais utiliser SOAP ou REST. Je pourrais utiliser Jersey ou Spring MVC/REST ou bien être un simple servlet qui prend une requête et renvoie des données au format JSON, XML ou String ou tout autre format requis.
De RESTful Web Services de Leonard Richardson et Sam Ruby, ISBN: 978-0-596-52926-0:
Les services Web ressemblent beaucoup aux applications Web, mais la création de ressources est l’un des endroits où ils diffèrent. La principale différence ici est que les formulaires HTML ne prennent actuellement en charge que GET et POST. Cela signifie que les applications Web doivent utiliser POST surchargé pour transmettre toute opération dangereuse.
Les services Web n'ont pas toujours une interface utilisateur. Elles sont normalement des API utilisant JSON, peuvent également être de type SOA utilisant SOAP et XML principalement, peuvent également être des sockets, des serveurs et autres micro services Web, etc.
Les applications Web peuvent être combinées de plusieurs manières. Il existe plusieurs façons de créer votre application en orchestrant plusieurs services Web, et une interface graphique distincte pour les contrôler, qui est liée à ces services. L’autre façon de ne pas utiliser les services est d’incorporer de manière procédurale du code dans votre application d’interface utilisateur, ou mieux, de créer une application orientée objet disposant de ses propres services séparés dans le modèle, auxquels le contrôleur a accès, et qui a sa propre vue une interface graphique qui accède aux services dans le back-end, ou même des applications plus complexes qui transmettent des services A2B, B2B, B2C à partir d'une interface graphique.
Les services n'ont pas toujours une interface graphique, ils peuvent avoir un CRUD pour gérer les données, mais une fois que vous commencez à avoir ces types de fonctionnalités, cela devient une application à part entière. Les services sont appliqués à quelque chose de plus grand qu'eux-mêmes. cette application crée votre application. Il doit avoir un but. Normalement, votre application nécessite plus d’un service aveugle, et il existe une sorte d’interface.
Si vous envoyez aveuglément une demande uri à votre service et que celui-ci renvoie aveuglément un message json, c'est un service. Qu'est-ce qui envoie ça aveuglément? Si vous, alors pas une application. Si une sorte de bricolage devient alors une application, le bricoleur est une interface graphique permettant d’accéder aux services et, dans son ensemble, à un système d’application de gestion de données. Maintenant, si vous placez une couche au premier plan pour afficher ces données de la manière d'un site Web, vous disposez désormais d'un produit pour afficher ces données, d'un produit pour le gérer et des données qui constituent le produit réel et qui sont accessibles via le service Web. , c’est maintenant une application complète. Votre effort pour créer cela devient votre application.
Je suppose que l’application Web par rapport au service Web, c’est le fait que le rapport de facteur de déploiement varie, ce qui signifie que le déploiement d’une application Web serait limité (localement) à ce qui est le cas dans le cas d’un service Web (globalement). Penser à la perspective de l'interface utilisateur est la meilleure option pour l'application Web, mais quand on pense à la programmation et la perspective du transfert de données, opter principalement pour un service Web . L'application Web nécessite l'utilisation de servlets avec des cadres tels que Spring mvc, etc. vouloir déployer la même application sur plusieurs plates-formes en faire un service Web via des implémentations Rest/Soap, de sorte que le comportement des applications Web soit remplacé par un service.
En bref,
WebService =
(RestApi/Soap) # added
/ | \
(client1)---(Web Application)---(clientN)
Je sais que c'est trop tard pour rejouer, mais je veux toujours
L’approche des services Web est bonne si
une. intégration d'entreprise avec uniquement des services Web, comme l'intégration de modules/applications distribués.
b. adapté aux applications distribuées
c. plus d'un consommateur pour le même service - comme les banques qui utilisent les données de l'agence d'évaluation du crédit
ré. les consommateurs veulent des données dans différents formats - comme un consommateur (client) veut au format XML, un autre serait dans JASON ...