web services - servicios - Servicio web vs aplicación web
web service rest php (9)
Sé que esta es una pregunta antigua y que ya me han respondido cientos de 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:
- Crea mi aplicación como una simple aplicación web.
- Crea 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?
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.
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 quieres decir es si deberías o no estar usando 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''.
JABÓN
Si su servicio tiene muchas funciones, los usuarios de Java y / o Visual Studio preferirían importar su archivo WSDL y utilizar su servicio como un objeto con todo el análisis XML hecho para ellos, por lo que SOAP sería la respuesta.
DESCANSO
Si solo tiene algunas funciones, con parámetros de entrada muy básicos y datos de respuesta, entonces SOAP podría ser excesivo.
MySite.com/Add/5/3
o
MySite.com/GetStockSymbol/Facebook
o
MySite.com/GetWeather/Paris/France
Creo que esto podría ayudarte a resolver tu confusión
Hay dos casos de uso principales de WEB en la industria
- De empresa a consumidor (B2C): cuando hay un consumidor que interactúa directamente con la empresa para sus necesidades, siempre usamos una aplicación web para proporcionar una comunicación entre dos partes.
- Business-to-Business (B2B): Significa que una parte del negocio necesita algunos insumos / servicios de otra parte del negocio. Siempre se usa un servicio web para cumplir los requisitos de negocio a negocio. Por lo general, un consumidor nunca interactúa con los Servicios Web directamente, solo interactuamos con una Aplicación Web y una Aplicación Web interactuamos con un Servicio Web para información / datos o procesamiento.
De RESTful Web Services por Leonard Richardson y Sam Ruby, ISBN: 978-0-596-52926-0:
Los servicios web son de hecho muy similares 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.
Hice esta pregunta hace más de 3 años y desde entonces ha corrido mucha agua debajo del puente. 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 aplicaciones web y servicios 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 si miro mi pregunta
Estoy creando una aplicación que será utilizada por otras aplicaciones (móvil / web) para buscar 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 "¡Amigo! 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 tomando una solicitud y 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.
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, servidores y otros servicios micro web, 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.
Sé que es demasiado tarde para reproducir, pero aún quiero
El enfoque de los servicios web es bueno si
a. integración empresarial con solo servicios web, como la integración de módulos / aplicaciones distribuidas.
segundo. adecuado para aplicaciones distribuidas
do. más de un consumidor para el mismo servicio, como bancos que consumen datos de la agencia de informes crediticios
re. los consumidores quieren datos en diferentes formatos, como un consumidor (cliente) quiere en formato XML, otro sería en JASON ..etc
Si pensamos en la terminología, que creo que es la pregunta 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.
La aplicación es el software que usa 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.
Por lo tanto, de cualquier forma que elija 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", de ser así).
Suena como en su caso, está construyendo un servicio web que proporciona datos con formato XML para múltiples aplicaciones. Entonces mi respuesta es: crea lo que ya estás construyendo y llámalo servicio web .
Si su aplicación no necesita una interfaz de usuario, entonces conviértalo en un servicio web. Si necesita una interfaz de usuario, entonces use una aplicación web.
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.
Usar SOAP generalmente es una mejor opción que el antiguo xml por estas razones:
Sus usuarios lo estarán esperando y es probable que ya sepan cómo leerlo.
Los entornos de desarrollo de los usuarios probablemente sabrán todo sobre SOAP y podrán 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 tus 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.