2012-01-24 12 views
15

Obtengo los beneficios de cambiar link uris, pero de eso no se trata en realidad esta pregunta.REST vs SOAP evolvability

Lo que quiero decir por evolvability es agregar nuevas características a un servicio o modificar (cuando sea posible) las existentes y eso es en realidad.

SOAP no es tan malo como la comunidad REST tiende a hablar de ello cuando se trata de la capacidad de evolución. Por ejemplo:

  1. En REST podemos agregar un nuevo relé SOAP, podemos agregar un nuevo método. Ambos tipos de clientes antiguos continuarán trabajando con nuevos servicios.
  2. En REST podemos agregar un nuevo campo de formulario y establecer su valor predeterminado: en SOAP podríamos tener argumentos de servicio como algunas clases ServiceArgs y agregar un nuevo campo a ServiceArgs. Eso es feo, pero funciona.

¿Cuáles son los ejemplos de evolvabilidad cuando los clientes SOAP se rompen y usted no puede hacer nada al respecto, mientras que los clientes REST manejan la situación con elegancia?

Gracias!

Respuesta

18

SOAP es una tecnología basada en contrato. Toda la interacción cliente/servidor se escribe y codifica en un documento grande (WSDL) y ambas partes deben acordarlo y respetarlo para que todo funcione. Si una de las partes decide agregar características, la otra parte debe "evolucionar" en paso de bloqueo con ella. Ambos lados están completamente acoplados, unidos por la cadera, pegados, casados, para siempre.

El enfoque típico para mejorar sus servicios SOAP es crear nuevos documentos WSDL para las nuevas versiones del servicio, y al mismo tiempo mantener los más antiguos. Otra técnica es crear una nueva interfaz para contener nuevos métodos y heredar de la anterior. El enfoque que describes en el n. ° 1 es que IMO infringe las reglas de SOAP, porque el cliente y el servidor ahora utilizarán diferentes contratos y solo funciona porque los cambios aditivos (como los nuevos métodos) pueden ser horneados y la mayoría de las veces las cosas funcionarán En el momento en que alguien hace un destructivo cambio, entonces el contrato del cliente no coincidirá con el servidor y se acabó el juego. Es un proceso difícil de gestionar, por lo que la mayoría de las organizaciones optan por crear un WSDL completamente nuevo para cada versión nueva de la API.

REST no desaparece mágicamente todos estos problemas, pero hace las cosas más fáciles de administrar al no forzarlo a agrupar todo el "contrato" de su sistema distribuido en un artefacto. ¿Estás usando HTTP? Genial, puedes usar todas las maravillosas funciones HTTP que usa la web también: servidores proxy, URLs, negociación de contenido, autenticación, etc. ¿Quieres comunicarte usando codificación JSON y XML? Knock a ti mismo. Es trivial hacerlo en REST en cualquier momento, sin afectar a los clientes existentes. ¿Quieres seguridad? Bien, comience a desafiar las credenciales autenticadas mediante el soporte incorporado de HTTP para eso exactamente. Todas estas cosas (HTTP, JSON, etc.) están estandarizadas y se describen en diferentes lugares y así es exactamente como debería ser.

SOAP combina el protocolo de transmisión, información de ubicación, descripción de carga útil, elección de codificación y métodos RPC en un documento descomunal. Si desea realizar algún cambio en cualquier elemento de esa lista, necesita un documento nuevo. Peor aún, algunas de esas cosas no se pueden cambiar en absoluto.

REST separa esas cosas para que las piezas puedan evolucionar independientemente. Sus URL (o "URI", para ser más precisos) se devuelven en tiempo de ejecución y suponiendo que el cliente doesn't start to hardcode them se puede modificar sin necesidad de realizar cambios al cliente. Los cambios adicionales en sus tipos de medios son triviales si su documentación deja en claro que pueden aparecer nuevos campos en el futuro. También tiene la opción de versionar sus tipos de medios, permitiendo la coexistencia de los tipos de medios v1/v2/v3 ... dentro de su sistema, y ​​el cliente puede elegir (utilizando los encabezados Accept y Content-Type en HTTP) cuál ellos quieren usar

¿Alguna vez escuchó el chiste sobre el dueño de Porsche que compra un auto nuevo cada vez que el cenicero se llena? Eso es JABÓN. Lo que debería ser un cambio trivial requiere una gran revisión. REST te da la aspiradora. No tiene que usarlo, pero es más barato.

+1

Gracias por la respuesta expandida. Claramente, los servicios SOAP son menos evolutivos que los RESTful. Sin embargo, SOAP permite cierto grado de evolvabilidad. No puede cambiar el formato y algunas otras cosas, pero puede agregar métodos y argumentos (con un pequeño truco descrito anteriormente). Como dices, eso violará las reglas de SOAP, pero ¿importa? Funciona. También dices que cuando alguien hace un cambio destructivo en un servicio SOAP se termina el juego. Es cierto para los servicios RESTful también. Si realiza un cambio destructivo en un tipo de medio y un cliente no puede encontrar un enlace, espera que también lo sea. –

+3

Re: agregar métodos a las interfaces SOAP (el "truco"): sí, funciona pero funciona por suerte, no por diseño. Es esencialmente una técnica no compatible. Con REST, su arquitectura puede evolucionar porque la evolución es esencial para REST, no está prohibida en un nivel básico como lo es con SOAP. Re: cambios destructivos: correctos en ambas cuentas. No es algo que ningún cliente programático pueda manejar mágicamente. –

Cuestiones relacionadas