Header Ads Widget

Ticker

6/recent/ticker-posts

Enfrentamiento de microservicios: REST vs SOAP vs Apache Thrift (y por qué es importante)

 

showdown_REST_SOAP_Apache_Thrift_nordic_APIs

El mundo de las API está cambiando. Si bien el panorama de API inicial estaba dominado en gran medida por monolitos , o una aplicación que proporciona todos sus servicios a través de una aplicación gigante y singular , la arquitectura de desarrollo de API moderna se ha ido moviendo constantemente hacia los microservicios . A diferencia de los sistemas monolíticos, los microservicios entregan su funcionalidad dividida entre múltiples aplicaciones y procesos separados, y brindan su funcionalidad a través de múltiples servidores cuando es necesario.

A medida que ha crecido el desarrollo de microservicios, también lo ha hecho la necesidad de diseños de arquitectura más diversos y extensibles. En este artículo, vamos a echar un vistazo a dos de los gigantes del mundo de las API, REST y SOAP , así como a un aspirante al trono, Apache THRIFT.

Por qué es importante

Al desarrollar una API, una de las consideraciones más importantes en todo el ciclo de desarrollo es la arquitectura sobre la que se construirá el sistema. Las elecciones realizadas en esta fase de diseño pueden hacer o deshacer su API, convirtiendo un concepto útil y una aplicación inteligente en un fragmento de código inútil. ¿Por qué es esto? ¿Qué hace que la arquitectura sea tan importante? En pocas palabras, el tipo de arquitectura detrás de una API altera la forma en que se usa y la reacción a ese uso.

La perspectiva de la máquina

En primer lugar, considere el uso de su API desde una perspectiva de máquina . A medida que Internet ha crecido a pasos agigantados, también lo ha hecho el alcance de la tecnología que requiere; mientras que los servicios inicialmente tenían que atender unos cientos de solicitudes muy específicas a diario, los servicios modernos pueden atender miles de consultas y solicitudes en una cantidad casi impensable de permutaciones cada hora.

Debido a esto, la API moderna debe diseñarse para interactuar con los sistemas correctos, en el momento adecuado, utilizando los lenguajes correctos. Esto se hace primero en la arquitectura; después de todo, un rascacielos se construye utilizando una base mucho más sólida que una casa común y, en consecuencia, su API debe construirse con una base diferente según el peso de su cliente, las necesidades del sistema. y los requisitos generales de funcionalidad.

La perspectiva humana

Incluso cuando se consideran los requisitos técnicos de su API, todavía hay un abismo de posibles obstáculos y obstáculos. La experiencia del usuario cae directamente en este abismo. No importa qué tan bien interactúe su API con los datos y los sistemas, la entrega de estos datos al usuario es lo que se verá y juzgará públicamente: su base de usuarios y su tasa de uso dependerán directamente de ello. Diseñar su API para ofrecer primero una buena funcionalidad, facilidad de uso y una buena experiencia de usuario generará éxito, adopción y retención de usuarios.

Esto se trata en gran medida en la base de su API, al igual que con el diseño de máquinas. Si bien es importante considerar la estructura básica de su API, considerar la experiencia del usuario puede ayudarnos a alejar nuestra elección de una máquina, un modelo centrado en el servicio y más hacia un enfoque holístico .

Definición de SOAP, REST y Apache THRIFT

Ahora que sabemos lo importante que es crear una base sólida y funcional, ¿qué opciones tenemos en diseño arquitectónico? Si bien el mundo de las API está inundado de sistemas propietarios, estructuras experimentales y plataformas de diseño arcaicas, la mayoría de las arquitecturas se dividen en dos categorías: SOAP o REST .

SOAP , o Simple Object Access Protocol , es un concepto arquitectónico que fue creado en 1998 por Dave Winer, Don Box y Bob Atkinson, en colaboración con Microsoft . Diseñado explícitamente con el propósito de facilitar la comunicación entre servicios web, SOAP tiene cuatro características principales que lo hicieron tan popular en su infancia:

  1. Extensibilidad a través de extensiones generadas por el usuario vinculadas a la estructura base;
  2. Neutralidad operando sobre cualquier protocolo de transporte;
  3. Independencia al permitir paradigmas y estructuras de programación variable;
  4. Manejo de datos grandes mediante el manejo de conversiones, cálculos, etc. de forma asincrónica .

REST , o Representational State Transfer, fue creado en 2000 por Roy Fielding en UC, Irvine; Las versiones posteriores de esta arquitectura se crearon en colaboración con el Grupo de Arquitectura Técnica ( TAG ) del W3C Si bien SOAP tenía como objetivo ser un sistema completo, REST fue diseñado para ser más liviano para incorporar lo siguiente directamente en el diseño;

  • Escalabilidad mediante el uso de datos almacenados en caché del cliente y nodos intermedios integrados en HTTP para autodefinirse;
  • Portabilidad al vincular la transferencia de datos al código del programa durante la transferencia;
  • Extensibilidad al permitir que los elementos individuales de la red mayor se desarrollen de forma independiente entre sí, utilizando interfaces uniformes.

Durante un tiempo, las dos arquitecturas anteriores dominaron el mercado de API. El pensamiento común entre los diseñadores especificó que tu orientación era RESTful o SOAP; esta mentalidad cambió con un desarrollo significativo. En 2007, el gigante de las redes sociales Facebook publicó un documento técnico que detallaba un sistema de arquitectura interna sobre el que operaba la mayor parte de su sistema.

El servicio, llamado Thrift , pronto se lanzó como un proyecto de código abierto bajo la etiqueta Apache Software Foundation. La arquitectura, diseñada específicamente para competir con SOAP y REST mientras entrega datos rápidamente en varios formatos, incluye una pila completa para la fabricación, mantenimiento y expansión de clientes y servidores. El sistema fue diseñado específicamente para incluir:

  • Escalabilidad al admitir servicios en varios idiomas sin problemas entre C #, C ++, Cappuccino, Cocoa, Haskell y más;
  • Simplicidad al evitar los marcos de REST y XML de SOAP en favor de una biblioteca simple;
  • Velocidad mediante el uso de serialización binaria para manejar datos;
  • Evolución al permitir el control de versiones suave, el apoyo a equipos de terceros para desarrollar llamadas RPC según sea necesario;

Inconvenientes y beneficios de los microservicios

Dada la gran cantidad de opciones de protocolo que se ofrecen en estos días, ¿cuál es la mejor opción para una arquitectura de microservicio? Desafortunadamente, eso depende en gran medida de las características específicas de su sistema, aplicación o servicio en particular; sutiles minucias que pueden parecer poco importantes en el gran esquema de las cosas podrían cambiar dramáticamente la arquitectura elegida.

SOAP es una maravillosa arquitectura de elección cuando las necesidades del sistema no dejan lugar a malas interpretaciones. La facturación de facturas, la administración de recursos e incluso la administración de la ciudad pueden utilizar las metodologías de contrato estrictas y efectivas de SOAP. Además, los procesos que requieren mucho tiempo , como el procesamiento de una gran cantidad de datos de medios o el cálculo de las rutas de enrutamiento más eficientes, se benefician mejor con el diseño asincrónico de SOAP. Debido a que SOAP tiene estado por definición , los servicios que requieren los estados tanto del cliente como del servidor pueden usar SOAP de manera mucho más efectiva que REST. Las transferencias bancarias, las reservas de automóviles e incluso el seguimiento de revisiones con sistemas de actualización utilizan este sistema con estado en su máximo potencial.

REST se usa mejor en sistemas que no requieren esta información adicional; además de su mayor velocidad al evitar XML y la funcionalidad pesada del sistema, REST escala extremadamente rápido y es más extensible en un sistema dinámico que SOAP. Cuando se ve dentro del marco de una aplicación web, REST es un candidato natural debido al hecho de que hereda una gran parte de sus operaciones de la pila HTTP; Además, debido al hecho de que REST es menos restrictivo que SOAP, a menudo se considera que REST admite una mayor cantidad de funcionalidades experimentales y futuras.

Thrift , por otro lado, abarca lo mejor de ambos mundos. Si bien SOAP es muy extensible, es extremadamente detallado; Thrift se aleja de esto, optando por tamaños de archivo más pequeños y documentación más simple . Si bien REST y SOAP son arquitecturas maravillosas, están limitadas en los idiomas que hablan; Thrift funciona en binario y tiene soporte para lenguajes comunes como C, C ++, C #, PHP, Haskell, Go y más. Thrift es de código abierto, lo que significa que muchos grupos lo monitorean, lo modifican y lo rastrean, lo que lo hace más seguro y actualizado.

El mayor inconveniente de Thrift es el hecho de que es relativamente nuevo y, por lo tanto, está luchando contra un campo abarrotado para construir una base de usuarios sólida: SOAP tuvo una ventaja de 9 años en Thrift, una que REST casi igualó con su propia ventaja de 7 años. . Thrift comenzó detrás de la curva en términos de adopción; sin embargo, su uso ha crecido constantemente, con gigantes como Tumblr y Facebook impulsando la adopción a través de sus aplicaciones únicas e innovadoras.

Parte del atractivo de Thrift es la naturaleza progresista de la arquitectura: debido a su adopción de versiones suaves , las llamadas RPC se pueden desarrollar e implementar libremente con una biblioteca central o repositorio que funciona como una base de código estándar. A medida que surjan tecnologías futuras que requieren características más complejas, experimentales y con visión de futuro que las que pueden proporcionar REST o SOAP, Thrift se convertirá en una propuesta cada vez más atractiva.

A continuación, se muestra una comparación visual de las funciones de cada servicio web, utilizando los promedios de las puntuaciones recopiladas del equipo de API nórdicas:

DESCANSOJABÓNAhorro
Extensibilidad☆☆☆☆☆☆☆☆
Neutralidad☆☆☆☆☆☆☆☆☆
Independencia☆☆☆☆☆☆☆
Manejo de datos grandes☆☆☆☆☆☆☆☆
Escalabilidad☆☆☆☆☆☆☆☆☆☆☆
Portabilidad☆☆☆☆☆☆☆
Sencillez☆☆☆☆☆☆☆☆☆☆
Velocidad☆☆☆☆☆☆☆☆
Evolución☆☆☆☆☆☆☆

Ejemplos de códigos de casos de uso

Veamos los tres estándares usando un escenario común. En nuestros ejemplos, tenemos un host definido como “www.example.net, hemos construido nuestra arquitectura en el estándar SOAP y utilizamos solicitudes SOAP para obtener los datos de un usuario específico registrado en nuestra plataforma. En nuestros ejemplos, mostraremos la solicitud más básica posible en cada sistema.

Si usa SOAP , nuestra solicitud se vería así:



 
  
   555
  
 

Como puede ver, la solicitud SOAP utilizada es bastante detallada; Si bien cierta información detallada en el protocolo de mensajes SOAP puede dejarse vacía, como los elementos Encabezado y Fallo, se debe proporcionar una gran cantidad de información al servidor directamente envuelta en el mensaje.

Esto es parte del inconveniente de SOAP; a menos que los datos que se manejen no sean necesarios en tiempo real (es decir, en el caso del procesamiento de medios, gran recopilación de datos, etc.), SOAP puede ser considerablemente más lento que otras arquitecturas y es bastante detallado, a menudo hasta el punto de que La cantidad de datos proporcionados es demasiado detallada.

Consulte nuestra infografía REST vs SOAP

Ahora, veamos la misma solicitud en REST .

GET
www.example.net/resources/userdatabase/UserInfo/555

Como puede ver, la solicitud REST es mucho más simple, incluso la naturaleza del "método" de cada llamada es mucho más simple, con la llamada REST descartando GetUserInfo de SOAP para un método URL simple de UserInfo. Mientras que el método SOAP entregará los datos de acuerdo con la forma en que se construyen los sistemas y de acuerdo con la forma solicitada, el método REST entregará los datos en forma sin procesar.

Con Thrift , la solicitud es muy diferente.

service FindUserID 555 {
	results find(1: string name)
}

El truco aquí es que la mayor parte de la solicitud de Thrift se maneja dentro del servidor y está definida por el desarrollador de la API. Mientras que SOAP y REST pueden alterar sus solicitudes para modificar su salida de datos (en términos relativos, REST siempre entregará sus datos en un formato sin procesar a través de HTTP a menos que se utilice un servicio de terceros para interpretar los datos), las solicitudes de Thrift se definen y amplían internamente.

No hay necesidad de una metodología de fallas, de una delimitación de longitud máxima o de una búsqueda de ubicación específica, ya que todas están definidas en el servicio "FindUserID" en el propio servidor. Cuando SOAP o REST reciben una solicitud, necesitan consultar su arquitectura interna, archivos adicionales o la propia solicitud para obtener información sobre cómo procesarla. Cuando Thrift recibe una solicitud, este formato de manejo ya es conocido, porque es parte del propio sistema.

Comprensión de los servicios: metáfora del correo postal

Los temas complejos son más fáciles de manejar cuando se dividen en una historia reconocible. Entonces, para aquellos que no estén al tanto de estas sutilezas, ahora intentaremos comparar SOAP, REST y Thrift con el envío de una carta.

Digamos que quiere enviar una carta a su vecino diciéndole que deje de tocar la batería a las tres de la mañana. ¿Cómo haría usted para esto?

Bueno, si está utilizando SOAP , primero escriba una carta larga, luego colóquela en un sobre, imprima la dirección, la dirección del remitente y adjunte el franqueo. Estás envolviendo el mensaje de tal manera que el sistema de correo entienda quién, cómo y dónde entregarlo.

REST , por otro lado, es como una postal prepaga. Ha renunciado al sobre a favor de un dispositivo de entrega ligero y conciso que es fácil de interpretar y manejar, con su mensaje garabateado rápidamente en la parte posterior. La postal usa menos material (ancho de banda), generalmente tiene un contenido más corto y, de hecho, podría llegar a su vecino más rápido porque hay menos volumen para moverse.

Thrift es como un megáfono. Cuando apuntas con el megáfono a tu vecino, él sabe implícitamente que estás molesto por algo y que se lo vas a decir específicamente a él. Él sabe qué hacer con la información, porque la reacción de un ser humano a un megáfono es bastante universal (asumiendo, por supuesto, que su megáfono es más fuerte que su batería). El mensaje se envía de una manera liviana pero contundente que depende completamente del receptor para procesarlo correctamente, en este caso su vecino.

Conclusión

Sería fácil y conveniente decir que cualquiera de estas arquitecturas era "mejor" que la otra: tener una arquitectura estándar desde la cual trabajar universalmente facilitaría el desarrollo, la comunicación entre API más fluida y la adopción de nuevas tecnologías sería mucho más fácil. Desafortunadamente, este no es el caso; El mundo de las API es tan diverso que cualquier número de requisitos, advertencias y problemas únicos podría impulsar la adopción de cualquiera de las tres arquitecturas mencionadas anteriormente.

Sin embargo, al diseñar su API, vuelva a la metáfora anterior. En lugar de enviar solicitudes POST a través de la web, piense en cómo se procesaría el intercambio si estuviera utilizando papel real para solicitar información.

Si estuvieras solicitando datos de álbumes a una compañía discográfica, por ejemplo, ¿cómo lo harías? ¿Enviarías una postal? Probablemente no, ya que eso no le permitiría explicar específicamente por qué necesita los datos y en qué formato los quiere, al menos no tan bien como lo haría una carta. ¿Usarías un megáfono? Bueno, no, porque necesita un servicio específico de la forma en que lo solicita, no de la forma en que quien recibe su carta podría pensar que lo necesita. Entonces, decidiría por una carta, una carta simple con solicitudes simples. En este caso, puede elegir SOAP sobre REST o Thrift, porque sus necesidades son específicas y SOAP cumple con los criterios de su solicitud detallada.

Tener en cuenta los requisitos específicos de su microservicio puede ayudarlo a tomar una decisión más informada; ya sea que la flexibilidad detallada de SOAP supere el almacenamiento en caché y la extensibilidad de REST, o si la escalabilidad de REST supere la visión de futuro rica en funciones de Thrift, su situación particular determinará su mejor curso de acción.

Publicar un comentario

0 Comentarios