¿Cómo se ha visto afectado el desarrollo de software de TI empresarial por la tendencia hacia las API RESTful?

Para mí, la TI empresarial puede significar tanto aplicaciones internas como externas / aplicaciones web creadas por una empresa de TI para su consumo interno y clientes externos, respectivamente. Creo que las API REST han impactado positivamente tanto

1. Aplicaciones internas: la API REST permite una clara separación de las preocupaciones del cliente y el servidor. La gran ventaja que tiene para una empresa es que pueden crear código del lado del servidor que puede reutilizarse en sus aplicaciones de escritorio, móviles y web. Por ejemplo, la mayoría de las empresas tendrán una búsqueda en el Directorio de sus empleados donde se pueden ver todos los detalles de contacto, departamento, jerarquía de la organización, etc. Exponer esta funcionalidad a través de las API REST permitirá que los puntos finales estén expuestos desde el servidor en recursos como / empleados (obtenga todos los empleados, obtenga detalles de un empleado, actualice un empleado), etc. y use un formato JSON simple para llamarlos desde su aplicación móvil, aplicación web o cliente de escritorio

2. Aplicaciones externas: muchas empresas suelen tener contratistas, proveedores y distribuidores que se conectan con su sistema. Estas entidades pueden tener sus propios sistemas en ejecución. Las API REST permiten proporcionar una interfaz limpia a estas partes externas para conectar sus sistemas con los sistemas empresariales. Las compañías de TI en particular también pueden tener servicios que son consumidos por desarrolladores y usuarios finales. Las API REST brindan una forma de exponer estos servicios de manera transparente y brindan los beneficios de la personalización y la extensibilidad

No significativamente Las empresas en general no requieren lo que el paradigma REST tiene para ofrecer, o tienen medios más tradicionales para lograr los mismos resultados.

El beneficio clave de REST es la capacidad de ofrecer un amplio conjunto de interacciones al tiempo que se basa en una pila de tecnología muy simple y universalmente compatible. Casi cualquier cosa puede consumir servicios REST siempre que comprenda HTTP (S). En la escala de Internet, esto reduce la barrera de entrada para las tecnologías del lado del cliente e impulsa la adopción. Las empresas, por otro lado, tienen una tendencia a estandarizar la lista de tecnologías (principalmente desde la perspectiva de mitigación de riesgos), por lo que realmente no enfrentan el desafío de la proliferación incontrolada de pilas de aplicaciones. En aras de la discusión, la mayoría de las pilas útiles utilizadas para el desarrollo de aplicaciones empresariales son compatibles con los estándares WS- * o AMQP.

Otra razón importante es que, en los casos en que se requieren interacciones complejas, REST pone énfasis en las aplicaciones del cliente para desarrollar esa complejidad (aunque contribuye en gran medida a garantizar que no sea muy onerosa). Los proveedores de servicios no tienen responsabilidad por lo que hacen sus clientes. Si considera todo el ‘ecosistema’ de un importante servicio de Internet y sus consumidores, habrá una duplicación significativa de esfuerzos entre estos últimos para ‘orquestar’ interacciones complejas y garantizar la solidez de sus soluciones. Se produce una gran cantidad de optimización local, pero eso está bien en Internet. De hecho, esto no concierne a nadie, ya que no hay autoridad sobre los proveedores de servicios y los consumidores de servicios.

Esto es diferente del contexto empresarial típico en dos formas importantes. En primer lugar, las empresas quieren optimizar ‘globalmente’ y reducir la duplicación de código en todo su estado de TI, por lo que hacer que cada consumidor vuelva a implementar y mantener una lógica de orquestación compleja es un desperdicio. En segundo lugar, las empresas deben garantizar un entorno operativo estable para soluciones integrales, no solo servicios y consumidores por separado. Ambos controladores conducen ahora a la adopción del paradigma Enterprise Service Bus (ESB), donde toda la lógica de integración / orquestación se concentra en una sola capa arquitectónica: middleware de integración de aplicaciones, que también permite una función de soporte de aplicaciones centralizada para garantizar su fluidez. operación. Este es un enfoque más rentable en comparación con el anterior, pero simplemente no es posible en Internet.

Hay otros matices más sutiles. No voy a entrar en detalles, pero quiero mencionar algunas: aplicaciones ‘heredadas’, algunas de las cuales ni siquiera entienden las redes (solo pueden leer archivos), integraciones B2B que conllevan riesgos significativos (considere un pago de $ 100 millones), proliferación de soluciones construido por usuarios finales sobre MS Office. Nada de eso puede simplificarse con REST. Los beneficios de las API RESTful que brillan en Internet simplemente no se materializan en el contexto empresarial y, como resultado, pasan desapercibidos.

En primer lugar, debemos entender que REST es un estilo arquitectónico, por lo que no se solucionó nada. Como en elegir sus propias pautas.

De todos modos, está claro que REST tiene muchas ventajas cuando se trata de la interacción de servicios. Entonces, lo que están haciendo las empresas (al menos las empresas que conozco) es ofrecer una capa REST Open API sobre su arquitectura. Y eso es solo oro: ya que les permite ofrecer sus propios datos como servicio y venderlos. Pero también para integrar servicios de terceros en su ecosistema (por ejemplo, webhooks).

En algún momento en el futuro, espero que se den cuenta de que la misma victoria “fácil” que pueden lograr al abrir interfaces para el mundo externo podría tener muchas ventajas, incluso internamente. Esta simple razón podría transformar la forma en que funciona una empresa y se organiza internamente. Piense en microservicios, virtualización y contenedorización, etc.

TLDR; Las empresas están utilizando API RESTful además de sus infraestructuras existentes. Por lo general, se introduce una puerta de enlace API para administrar el ciclo de vida API. SOnnesr o posterior se darán cuenta del potencial real de las API también internamente. Probablemente a largo plazo esto transformará incluso la organización de las empresas.

editado: error tipográfico