Servicio web vs aplicación web

Question

Sé que esta es una pregunta antigua y que ya se la debe haber respondido cien veces, pero todavía no puedo encontrar una respuesta satisfactoria.

Estoy creando una aplicación que será utilizada por otras aplicaciones (móvil/web) para buscar los datos. Ahora tengo 2 opciones:

1. Crear mi aplicación como una simple aplicación web.
2. Cree un servicio web.

Un servicio web se ve más sofisticado donde cualquier cliente proporcionará los datos en un formato específico (SOAP/REST) ​​y mi aplicación analizará la solicitud y devolverá los datos solicitados por el cliente. Cómo se usarán los datos no es problema de mi aplicación.

Mi pregunta es que lo mismo se puede lograr con una simple aplicación web que acepte la solicitud en formato XML y responda con una respuesta XML. La sensación principal es que un servicio web será una mejor forma de acceder a este tipo de servicio en el que no estamos seguros de quién lo usará. Pero, ¿hay alguna ventaja específica de usar un servicio web sobre una simple aplicación web?

Answer 1

En un nivel bajo, las aplicaciones web y los servicios web son casi lo mismo. Ambos operan en http (s). SOAP es solo una versión bien definida de XML. REST es algo así como HTTP. Si lo desea, podría hacer que una aplicación web se parezca a los servicios web y viceversa.

La principal diferencia serían las opciones de desarrollo interno basadas en la plataforma que está utilizando. Si, por ejemplo, está usando Visual Studio, entonces agregar una aplicación de servicio WCF le dará un proyecto que está orientado de forma predeterminada hacia WCF. Pero elegir cualquier otro tipo de aplicación no evitará que agregue servicios web.

usando jabón es generalmente una opción mejor que la antigua llanura xml por estas razones:

• Sus usuarios estarán esperando, y es probable que saber leer ya.

• Es probable que los entornos de desarrollo de sus usuarios sepan todo sobre SOAP y puedan interpretarlo de la caja. (Si proporciona un archivo WSDL, muchos usuarios podrán usar un script para generar sus clases en segundos).

• Es más probable que sus mensajes estén bien definidos. Estoy trabajando en un proyecto en el momento en que el otro lado ha definido su propia estructura XML aleatoria y es una pesadilla trabajar con ella. Nunca sé qué esperar, y hay poca consistencia entre sus diferentes tipos de mensajes. Al menos, si hubieran aceptado conformarse con SOAP, entonces podría haber sido mucho más fácil interpretar sus mensajes.

Answer 2

Si su aplicación no necesita una interfaz de usuario, conviértala en un servicio web. Si necesita una interfaz de usuario, entonces use una aplicación web.

Answer 3

Mi pregunta es que puede conseguir lo mismo por una aplicación web sencilla aceptar la solicitud en formato XML y responder con una respuesta XML.

Ese es un servicio web. Creo que este es un problema de terminología.No tiene otra forma de resolver esto que usar un servicio web, ya sea que sea relajante o basado en SOAP depende de usted, pero si está transfiriendo datos a clientes en formato XML, en respuesta a solicitudes XML, se trata de un servicio web.

Sospecho que lo que quiere decir es si debe o no utilizar un servicio web RESTful o un enfoque basado en SOAP complicado. Para mí, la respuesta depende de cuántas funciones se necesitan en su 'Servicio'.

de SOAP

Si el servicio tiene un montón de funciones que los usuarios de Java y/o visual studio prefieren importar el archivo WSDL y utilizar su servicio como un objeto con todos los análisis XML hecho por ellos , entonces SOAP sería la respuesta.

RESTO

Si sólo tiene unas pocas funciones, con parámetros de entrada y los datos de respuesta muy básica, a continuación, jabón podría ser excesiva.

MySite.com/Add/5/3 

o

MySite.com/GetStockSymbol/Facebook 

o

MySite.com/GetWeather/Paris/France 

Answer 4

Si pensamos en la terminología, que creo que es la cuestión principal aquí.

El servicio web se refiere al software, que sirve datos en cualquier formato (XML/JSON, etc.) a través de algún tipo de interfaz web. Esa interfaz se puede llamar API (interfaz de programación de aplicaciones). REST y SOAP son formas de diseñar la API.

Aplicación es el software que está utilizando esta API proporcionada por el servicio web.

En otras palabras, el servicio web es "servidor" y la aplicación es "cliente". Por lo general, el servidor sirve máquinas y los clientes sirven al usuario.

Así que de cualquier forma que elija para construir su sistema, yo llamaría a la parte que sirve los datos como "servicio web" y la parte que utiliza los datos como "aplicación" (o "aplicación web").

Suena como en su caso, está creando un servicio web que proporciona datos con formato XML para múltiples aplicaciones. Así que mi respuesta es: construye lo que ya estás construyendo y llámalo servicio web.

Answer 5

Sé que es demasiado tarde para volver a reproducir, pero todavía me quieren

enfoque de Servicios Web es bueno si

a. integración empresarial con solo servicios web, como la integración de módulos/aplicaciones distribuidas.

b. adecuado para aplicaciones distribuidas

c. más de un consumidor para el mismo servicio - como los bancos que consumen datos de Credit Reporting Agency

d. los consumidores quieren datos en diferentes formatos - como un consumidor (cliente) quiere en formato XML, otro sería en JASON ..etc

Answer 6

Creo que esto podría ayudar a resolver su confusión

Hay dos casos de uso principales de la Web en la industria

1. de empresa a consumidor (B2C): Siempre que haya consumidor directamente interactuando con el negocio para sus necesidades siempre usamos una aplicación web para proporcionar una comunicación entre dos partes.
2. Business-to-Business (B2B): Significa que una parte de la empresa necesita algunas entradas/servicios de otra parte de la empresa. Siempre se utiliza un servicio web para cumplir los requisitos de empresa a empresa. Por lo general, un consumidor nunca interactúa con los servicios web directamente. solo interactúa con una aplicación web y una aplicación web interactúa con un servicio web para información/datos o procesamiento.

Tomado de http://coder2design.com/java-interview-questions/

Answer 7

hice esta pregunta más de 3 síes atrás y mucha agua ha corrido bajo el puente desde entonces. He trabajado en decenas de aplicaciones web y he creado cientos de servicios web. Entonces, creo que tiene sentido responder mi propia pregunta aquí.

El desafío al que me enfrenté cuando formulé esta pregunta fue que me confundí entre los términos aplicación y servicio (tenga en cuenta que la web es un elemento común en la aplicación web y el servicio web). Como su nombre sugiere, la aplicación es una aplicación en sí misma, mientras que un servicio está destinado a servir a los demás. Un servicio probablemente no tiene ningún significado a menos que alguien lo vaya a usar. Puede servir una o más aplicaciones o servicios.

Ahora bien, si miro a mi pregunta

Estoy creando una aplicación que será utilizado por otras aplicaciones (móvil/web) para recuperar los datos. Ahora tengo 2 opciones, 1. para crear mi aplicación como una simple aplicación web 2. Para crear un servicio web.

Me gustaría decirme a mí mismo que "Dude! Si hay una entidad que toma una solicitud y devuelve datos, estás hablando de un servicio". Porque no estoy preocupado por lo que va a pasar con esa información? ¿Quién lo usará? ¿Cómo se mostrará eso?

Estoy realizando una solicitud y estoy devolviendo datos. Ahora cómo lo estoy haciendo eso es parte de la implementación. Podría usar SOAP o REST. Podría usar Jersey o Spring MVC/REST o puede ser un servlet simple que toma una solicitud y devuelve datos en JSON o XML o String o cualquier otro formato requerido.

Answer 8

Los servicios web no siempre tienen una IU. Normalmente son API que utilizan JSON, también pueden ser de tipo SOA utilizando principalmente SOAP y XML, también pueden ser sockets y servidores y otros servicios web micro, etc.

Las aplicaciones web se pueden juntar de muchas maneras. Hay varias maneras de crear su aplicación mediante la orquestación de múltiples servicios web, y una interfaz gráfica de usuario separada para controlarlos que se relaciona con estos servicios.La otra forma que no usa servicios es incorporar código en su aplicación de interfaz de usuario, o mejor aún, hacer una aplicación Orientada a Objetos que tenga sus propios servicios separados en el Modelo más tarde, a la que acceda el controlador, y que tenga su propia vista como una GUI que accede a los servicios en la parte de atrás, o incluso aplicaciones más complicadas que pasan servicios A2B, B2B, B2C desde alguna GUI.

Los servicios no siempre tienen una GUI, pueden tener un CRUD para mantener los datos, pero una vez que comienzas a tener este tipo de características, se convierte en una aplicación en sí misma. Los servicios se aplican a algo más grande que ellos mismos. esta aplicación crea tu aplicación. Tiene que tener un propósito. Normalmente se necesita más de un servicio oculto para completar su aplicación, y existe algún tipo de interfaz.

Si simplemente envía ciegamente una solicitud de uri a su servicio, y envía ciegamente a json, eso es un servicio. ¿Qué está enviando ciegamente esto? Si usted, entonces no es una aplicación. Si se trata de una especie de crud, entonces se está convirtiendo en una aplicación, la crud es una GUI para acceder a los servicios y, en general, es un sistema de aplicación de administración de datos. Ahora, si coloca una capa en el frente para demostrar esta información en forma de sitio web, ahora tiene un producto para mostrar esta información, un producto para administrarlo y los datos que son el producto real y al que se puede acceder a través del servicio web. , ahora está lleno en la aplicación. Su esfuerzo al crear esto se convierte en su aplicación.

Answer 9

De RESTful Web Services por Leonard Richardson y Sam Ruby, ISBN: 978-0-596-52926-0:

servicios Web son de hecho muy similar a las aplicaciones web, pero la creación de recursos es uno de los lugares donde difieren. La principal diferencia aquí es que los formularios HTML actualmente solo admiten GET y POST. Esto significa que las aplicaciones web deben usar una POST sobrecargada para transmitir cualquier operación insegura.