2011-12-27 19 views
6

Hay 2 tipos de servicios web, tal como lo conozco. El primero es los mensajes formateados xml personalizados y el segundo mensaje xml estándar SOAP. Cuáles son las diferencias entre ellos? ¿Cuál es mejor, cuáles son los pros y los contras de cada uno de esos dos enfoques?¿Cuál es la diferencia entre el servicio web ordinario y el servicio web basado en jabón?

+0

creo que a continuación dos enlaces pueden ayudarle. http://www.eggheadcafe.com/community/xml/4/82443/difference-between-xml-and-soap.aspx http://stackoverflow.com/questions/80112/whats-the-difference-between-xml -rpc-and-soap –

Respuesta

5

"Servicio web" se refiere a un concepto más abstracto y general. Podemos decir que todo lo que se puede publicar en la web es un servicio web. Los Servicios web SOAP o los servicios RESTful son un tipo especial de servicios web que tienen una amplia aceptación y tienen sus propios estándares. Si bien los servicios SOAP se basan en un nuevo estándar basado en XML, el enfoque RESTful hace uso de los métodos HTTP existentes, por lo tanto, es más ampliamente aceptado (según mi experiencia).

+0

"Hay una comparación compacta en [link given]". No, no! –

+0

Parece que el enlace está muerto; los moderadores eliminaron la página. Eliminé esa oración refiriéndome a la página muerta. – anilsinaci

24

Por "ordinario", supongo que te refieres a los servicios RESTful. Esta discusión sería muy larga, así que voy a tratar de darle algunos puntos clave:

  1. servicios REST son el sabor más utilizada de Servicios Web. Están estrechamente vinculados a la funcionalidad y los principios de HTTP y se puede acceder tan simple como una solicitud GET (otras operaciones son POST, DELETE y PUT). El concepto central es el "recurso" que se identifica mediante un URI. Los formatos comunes para REST son XML y JSON. Es una tecnología bastante sencilla y fácil de usar, que es lo que la hace ampliamente disponible.

  2. servicios web SOAP están basados ​​en XML, la mayoría de ellos se adhiere al estilo RPC de diseño de aplicación (llamada a métodos remotos en un servidor y obtener una respuesta), y el uso de 3 pilares principales:

    • WSDL - Lenguaje de descripción de servicios web: se utiliza para describir un servicio en términos de operaciones disponibles, parámetros, etc.
    • SOAP - Protocolo simple de acceso a objetos: se utiliza para construir mensajes de interacción entre las entidades involucradas (cliente, servidor).
    • UDDI - Descripción universal, descubrimiento e integración: se usa para clasificar y publicar servicios web disponibles en un repositorio y permitir el descubrimiento por usuarios potenciales.

servicios web SOAP tienden a tener altos gastos indirectos y generalmente tienen mensajes muy detallados, pero puede ser bueno si es necesario implementar funcionalidades más complejas y la interacción en la aplicación.

+1

Desearía poder votar más de una vez. Esta es en realidad la mejor respuesta de todas. – Dienekes

+0

+1 Aquí estoy de acuerdo! – Pinch

11

Estrictamente hablando, solo los servicios de Soap son servicios web. Se basan en el WS-* Specs estandarizado por W3C y Oasis. A veces, también se hace referencia a un servicio web como POX-Endpoint (plain old XML) o REST Endpoint, que le permite obtener simplemente un XML sin procesar a través de HTTP GET.

Los servicios SOAP llevan su esquema en forma de un punto final wsdl (normalmente, anexa? Wsdl al punto final del servicio), por lo que hay muchas herramientas para crear objetos proxy y ocultar la complejidad de la llamada al servicio web. Con los servicios de POX, debe saber qué esquema usar, p. Ej. la documentación.

Los servicios SOAP llevan la carga útil dentro del sobre SOAP (un esquema XML con encabezado y cuerpo con la carga útil en el cuerpo). Tener un encabezado independiente de la carga permite redirigir el contenido, firmar y encriptar, autenticar, etc. sin conocer el contenido. Pero pagas por una sobrecarga adicional en el mensaje mismo.

POX, por otra parte, deja todo eso al servidor web y se basa generalmente en HTTP para autenticación y compresión. La inscripción y la firma deben ser realizadas por su sistema. Es baja sobrecarga pero también baja detectabilidad.

Lo que mejor funciona para usted depende en gran medida de su situación. Si trabaja en .Net o Java World, a menudo le resulta más simple crear un proxy y usarlo para trabajar con los servicios web como objetos remotos. Obtienes una infraestructura de construcción de pozo y una experiencia de programación cómoda. Si su entorno no es compatible con la generación de proxy o si debe ser llamado desde cualquier lugar, es posible que POX sea mucho más ligero.

Cuestiones relacionadas