Header Ads Widget

Ticker

6/recent/ticker-posts

¿REST es mejor que SOAP? Sí, en algunos casos de uso

 ¿Qué es REST? ¿Y SOAP? ¿Por qué fueron creados y cuáles son sus principales características? ¿Qué los hace diferentes y cuándo debería usar uno u otro? Dimos una descripción general de REST frente a SOAP en nuestra infografía reciente, pero esta publicación profundiza más. Siga leyendo para obtener respuestas a estas preguntas y una explicación sobre qué casos de uso se prestan a un enfoque RESTful y dónde es preferible SOAP.

¿REST es mejor que SOAP?  Sí, en estos casos de uso

Después de leer este artículo, conocerá la historia de los dos enfoques importantes para la creación de servicios web que se establecieron hace más de una década. A pesar de su edad, no se han alejado mucho de sus orígenes a lo largo de los años y aún pueden coexistir para abordar diferentes necesidades. Aprenderá que REST nació en el mundo académico, adoptando la filosofía de la Web abierta, mientras que SOAP fue concebido por grandes empresas de software con el objetivo de satisfacer las necesidades del mercado empresarial. Finalmente, podrá comparar ambos protocolos y decidir por sí mismo si debe usar REST o SOAP en su próxima implementación de API. Comencemos mirando a REST.

¿Qué queremos decir exactamente con REST?

REST, o “Representational State Transfer”, fue creado por Roy Fielding en 2000. Se introdujo por primera vez en su tesis doctoral en la que explora varios estilos arquitectónicos basados ​​en redes. REST se describe detalladamente en el capítulo 5 de su disertación. En esta sección, afirma en resumen que REST “proporciona un conjunto de restricciones arquitectónicas que, cuando se aplican como un todo, enfatizan la escalabilidad de las interacciones de los componentes, la generalidad de las interfaces, la implementación independiente de los componentes y los componentes intermedios para reducir la latencia de la interacción, reforzar la seguridad, y encapsular los sistemas heredados ".

Por lo tanto, REST se puede describir como una forma de crear servicios web siguiendo un conjunto de restricciones específicas entre consumidores y proveedores:

  • Separación de preocupaciones entre clientes y servidores: siguiendo este enfoque, los clientes no deben preocuparse por el almacenamiento de datos, al igual que los servidores no deben preocuparse por las interfaces de usuario. Esto disocia completamente el desarrollo de clientes y servidores y permite el uso de economías de escala.
  • La comunicación entre clientes y servidores debe ser sin estado : los servidores no deben almacenar ninguna información sobre el contexto de los clientes entre llamadas, con la excepción de la información de sesión que se utiliza para mantener la autenticación.
  • Los clientes deben poder almacenar en caché las respuestas: todas las respuestas del servidor deben contener suficiente información relacionada con la caché. Luego, los clientes pueden confiar en esa información y decidir por sí mismos si es apropiado o no almacenar en caché las respuestas.
  • Las conexiones pueden ocurrir a través de varias capas de comunicación : los clientes no deberían poder distinguir si están conectados directamente al servidor de aplicaciones oa un agente intermediario que transmite la información. Esto permite el uso de servidores proxy y varias otras formas de tecnología de escalabilidad.

REST a menudo se ha malinterpretado y no se ha implementado de acuerdo con la visión original de su creador. Esto ocurre en algunas situaciones principalmente porque una API es muy fácil de implementar usando marcos. Según Jakob Mattsson , quien dio una presentación relacionada en la Cumbre de la Plataforma Nórdica de API , REST en sí "es una abstracción de la Web". Mattsson explica que REST debería permitir que cualquier consumidor interactúe con la API de la misma manera que una persona interactúa con cualquier página web, sin tener conocimiento previo de cómo funciona. En consecuencia, la mayoría de las API utilizan sólo un subconjunto de todas las capacidades de REST, aprovechando la simplicidad proporcionada por de HTTP GETPOSTPUTDELETEmétodos en sus implementaciones.

¿Te acuerdas de SOAP?

SOAP, o "Protocolo simple de acceso a objetos", como se denominó originalmente, fue concebido en 1998 por un grupo de personas que colaboraban con Microsoft. Una de esas personas, Dave Winer , también fue el creador de XML-RPC, un protocolo de "Llamada a procedimiento remoto" que utiliza XML como estándar para los cuerpos de los mensajes. Fue este desarrollo el que condujo a la creación de SOAP. A pesar de haber sido apoyado por Microsoft, IBM y otros, SOAP solo fue reconocido oficialmente por el W3C en 2003 cuando lo propusieron como recomendación .

El uso de SOAP por parte de los servicios Web se ajusta a un conjunto de características que posibilitan la comunicación entre objetos distribuidos:

  • El protocolo es extensible : se pueden construir y utilizar extensiones a las funcionalidades básicas sin afectar las características principales.
  • El contenido del mensaje debe ser independiente del mecanismo de transporte: SOAP puede funcionar no solo a través de HTTP, sino también sobre otros protocolos de transporte como SMTP. Se ha utilizado SOAP sobre SMTP para proporcionar comunicación asincrónica entre clientes y servidores.
  • También debe estar desacoplado del modelo de programación subyacente: los desarrolladores deben poder desarrollar clientes o servidores SOAP sin ninguna restricción en la lógica o filosofía que siguen.

Habiendo gozado de gran popularidad durante sus primeros años de vida, el uso de SOAP ha ido disminuyendo con el tiempo. SOAP todavía se usa con mayor frecuencia en el mundo empresarial, donde la comunicación entre diferentes servicios debe ajustarse a un conjunto de reglas y contratos. Debido a que sigue objetos, reglas y restricciones, SOAP es un protocolo más estricto que REST. El uso de SOAP ganó popularidad entre las organizaciones más grandes, en parte porque era un mercado que Microsoft dominaba en ese momento. El Windows Communication Foundation (WCF), núcleo de desarrollo en plataformas de Microsoft, todavía soporta SOAP de hoy. Otras formas populares de implementar clientes y servidores SOAP incluyen PHP Zend Framework y Apache CXF .

Casos de uso donde REST es mejor que SOAP

Mientras que SOAP proporciona formas de acceder y manipular objetos de forma remota, REST se centra en las operaciones que se pueden ejecutar en los recursos. En parte debido a esta distinción, REST ha ganado una adopción masiva entre los profesionales de API públicas. Además, dado que REST hereda las operaciones de HTTP, es la opción más obvia a la hora de decidir cómo abrir una API web. Ha demostrado ser tan influyente que todas las principales empresas web ahora utilizan y fomentan el uso de API RESTful.

REST siempre es mejor que SOAP en situaciones que no requieren que mapees completamente un conjunto de objetos al cliente. La comunicación de información de objetos de un lado a otro puede consumir una gran cantidad de ancho de banda, que puede ser limitado en entornos donde la conectividad es costosa. Una API consumida principalmente por aplicaciones móviles es uno de los casos de uso en los que debe evitar SOAP a toda costa.

Otro factor es la simplicidad del protocolo REST en comparación con SOAP. Si le importa cuánto tiempo les toma a los desarrolladores interactuar primero con su API, REST siempre gana. ¿Qué es más fácil que hacer una GETllamada HTTP a una URL y recibir una respuesta a cambio? JSON incluso facilita las cosas al establecer una forma estandarizada de serializar y consumir cargas útiles de API. La mayor ventaja de JSON es su conexión con JavaScript y el navegador, lo que simplifica el desarrollo de aplicaciones ricas que consumen API.

Además, debido a que es menos restrictivo que SOAP, las supuestas API REST funcionan mejor en la naturaleza abierta de la Web actual. Los desarrolladores no están tan preocupados por los contratos como por la facilidad de uso de una API. Las API públicas cambian todo el tiempo porque las empresas necesitan adaptarse rápidamente. En esta realidad de startups y API sin acuerdos contractuales específicos, REST es una elección natural. El uso de SOAP en este entorno sería contraproducente, ya que podría introducir una complejidad contractual innecesaria.

Conclusión

REST y SOAP son de mundos completamente diferentes. Mientras que REST se ocupa más de las operaciones que se pueden realizar en entidades web, SOAP se centra en cómo acceder y manipular objetos de forma remota. RESTO fue construido sobre los cimientos de la propia web de la operación básica de apalancamiento HTTP ( GETPOST, etc.) y esto es lo que lo convierte en un candidato perfecto en cualquier implementación de la API pública. SOAP utiliza XML y proporciona un conjunto de características que permiten a los profesionales definir contratos entre consumidores y proveedores, algo muy valioso en el mundo empresarial.

Evite el uso de SOAP en aquellas situaciones donde el ancho de banda es muy limitado. SOAP necesita comunicar información sobre objetos y sus estados mediante XML Infoset. Normalmente, estos modelos de datos se serializan como XML textual. Esto, en comparación con las implementaciones REST típicas, consume significativamente más ancho de banda. Todas las restricciones de SOAP que funcionan tan bien en el mundo empresarial son contraproducentes cuando se dirigen a la Web abierta. En el clima empresarial actual, que generalmente no requiere el uso de contratos estrictos a largo plazo entre clientes y servidores, tales restricciones no son útiles en absoluto. Sin embargo, SOAP todavía está en uso activo, pero no tanto en las API web públicas.

¿Estás usando SOAP? ¿En qué manera? ¡Deje un comentario aquí o póngase en contacto para discutir esto más!

Publicar un comentario

0 Comentarios