¿Por qué usar servicios (REST / SOAP) en lugar de una biblioteca?

Digamos que está buscando dividir sus aplicaciones en servicios. ¿Hay alguna buena razón para adoptar un enfoque SOA en lugar de crear una API de biblioteca que las aplicaciones que la necesitan puedan cargar?

La diferencia puede ser sutil entre ambos. Por ejemplo, en el mundo .NET, es posible que tenga una aplicación que parezca monolítica para un usuario final y que funcione en una misma máquina, pero en el interior, se separe en un montón de servicios WCF. También puede tener arquitecturas donde las bibliotecas no están fuertemente vinculadas (complementos / complementos) y solo están siguiendo un protocolo cuando se hablan entre sí.

Si evitamos hablar de esos casos intermediarios y tratamos solo con una biblioteca API fuertemente vinculada frente a un servicio REST separado, entonces puede considerar los siguientes puntos:

1. Se llama a una API de biblioteca en la misma máquina. Los servicios se pueden alojar en cualquier lugar y se puede llamar desde cualquier lugar. Si cuenta el alojamiento de la aplicación en varias máquinas por razones de rendimiento / escalabilidad / seguridad, es probable que necesite usar los servicios.

2. La situación es similar cuando se trata de usar un servicio por una aplicación implementada en varias máquinas. Por ejemplo, si está haciendo una aplicación para un banco que está haciendo algunos cálculos financieros, una forma es implementar la aplicación completa completa en cada escritorio y verse obligado a realizar actualizaciones de gran tamaño a cada cliente cada vez; otro enfoque sería alojar la parte de cómputo en los servidores e implementar en los escritorios solo una aplicación liviana con solo una interfaz de usuario y un montón de llamadas a esos servidores.

3. Si aloja un servicio REST, cualquiera puede usarlo: un usuario de Mac, una persona que usa Linux, etc. Si ha creado una biblioteca C # con Visual Studio y la distribuye como una DLL, olvídese de los usuarios (clientes ?) que no tienen Windows.

Otra ventaja de los servicios es que cuando actualiza el servicio, se implementa inmediatamente a todos los consumidores del servicio. Entonces, si solucionó un error o un problema de rendimiento, todos obtienen el beneficio tan pronto como el servicio actualizado se active, en lugar de tener que distribuir una actualización que la gente puede optar por ignorar.

Ventajas de la biblioteca:

• Menos gastos generales por llamada (solo salto o incluso en línea ) = puede aumentar el rendimiento
• Lo más simple que podría funcionar
• Sin riesgo de que el servicio centralizado caiga e impacte a todos los consumidores

Ventajas de servicio:

• Todos obtienen actualizaciones de forma inmediata y transparente (a menos que se ofrezca una API versionada)
• Los consumidores no pueden descompilar el código
• Puede escalar hardware de servicio por separado
• Tecnología agnóstica. Con una biblioteca compartida, los consumidores deben utilizar una tecnología compatible.
• Más seguro. El nivel de IU puede llamar al servicio que se encuentra detrás de un firewall en lugar de acceder directamente a la base de datos.

Un enfoque SOA permite que los diversos servicios se alojen y mantengan por separado. Además del código, la implementación de un servicio en particular puede requerir mucha configuración especial (contraseñas, puertos, certificados, etc.). El consumo de un servicio REST tiene una cantidad finita de complejidad que se puede documentar claramente y comprender fácilmente. También es más seguro porque significa que no necesita otorgar acceso a bases de datos u otros recursos a los clientes.

Si hay un cambio en un servicio SOA, entonces ese servicio SOA tendrá que ser reconstruido, reexaminado y redistribuido. Todas las aplicaciones que consumen ese servicio pueden continuar haciéndolo. Un cambio a una biblioteca en una DLL significará que todos los consumidores de esa biblioteca tendrán que volver a desarrollarse para hacer referencia a esa DLL, todos tendrán que volver a probarse y todos tendrán que volver a implementarse. También existe el peligro de que esto no suceda correctamente, y diferentes aplicaciones tendrán diferentes versiones de la DLL. A veces, esto podría no ser un problema - quizás cada sistema debe tener la versión de la biblioteca que estaba presente en el momento del despliegue (es posible que haya actualizado su sistema de registro para tener nuevas características útiles - usted realmente¿necesita actualizar todos los sistemas con él?) en este caso, una biblioteca está bien. Pero supongamos que tiene un servicio para calcular la tasa de impuestos, y las leyes fiscales cambian. No desea tener que actualizar todos los sistemas para incorporar este cambio, sería mejor hacerlo en un solo lugar. En este caso, un servicio es una mejor opción.

Hay varias buenas respuestas, pero me gustaría agregar más cosas a las respuestas dadas:

El método de la biblioteca API es muy útil cuando desea interactuar con cosas con la menor sobrecarga posible. La consecuencia es que existe un mayor acoplamiento entre API y las aplicaciones que lo utilizan. A veces, esto está bien para la aplicación e incluso es necesario, sin embargo, si tiene un sistema muy distribuido o cree que la interoperabilidad es un gran problema, es posible que deba avanzar un paso más adelante y utilizar otras formas de comunicación. Especialmente, si desea tener un sistema distribuido, SOAP es una especie de siguiente paso en SOA, pero aún tendrá la dependencia entre las unidades, ya que deben conocer los procedimientos de cada uno. REST lo lleva a un nuevo nivel, al permitir que una máquina aprenda algo sobre el contenido de los otros servicios de manera unificada.

En su caso, si su aplicación no se distribuye, no veo ninguna razón para transformar su aplicación en SOA.