redes sociales

Leo en este artículo una no cosa curiosa… ¿Que SOA no está hecho pensando en la gente que lo va a consumir? me parece que no es así.

En primer lugar tenemos que dejar claro que SOA no es exclusivamente Web Services… se puede hacer SOA con REST por ejemplo… ambas, digamos “implementaciones” tienen sus pros y contras y como todo su ámbito de utilización. Una regla de la informática, y de casi todo en la vida, dice que hay que usar lo que sea más adecuado en cada ocasión.. si sólo pensamos en un martillo todo lo que veremos serán clavos….

Sigo pensando que REST es mejor para las comunicaciones en el interior de la empresa o desde clientes ligeros… sin embargo para las transacciones B2B, por ejemplo entre un banco y una aseguradora,  creo que es mejor WS-*.

¿Qué por qué digo esto? Por que WS-* está mucho más desarrollado en cuanto a necesidades de cifrado, firma, etc. etc. Características que pueden ser necesarias para este tipo de escenarios, donde se pueden estar vendiendo productos entre empresas y se necesita, además de la confidencialidad y la garantía de conocer la identidad del comprador, el no repudio de la transacción, etc. etc. Por otra parte, al día de hoy, es el único estándar de definición de contrato de servicio (el fichero WSDL) que está verdaderamente extendido y que se usa en el mundo real…

Dejando aparte esto de la diferencia entre REST y SOAP, que creo que muchas veces se exponen como contrapuestos cuando no lo son. En mi opinión, simplemente son dos formas de implementar una arquitectura SOA.

Y entonces ¿que hay de diferente entre SOA y API?… si vamos a la literalidad de las siglas vemos que SOA es una arquitectura (entendiéndose como una forma de diseñar software) y API un interfaz de programación, es decir, una forma de exponer la funcionalidad de un componente software a otro componente (que desempeña el rol de cliente).

¿Qué diferencia hay entre los APIS actuales, por ejemplos los que proporcionan las redes sociales como Twitter, Facebook…? Que ahora, en lugar que el cliente y la parte proveedora del API estén ejecutándose en el mismo programa, existe una red de por medio… es decir, que son totalmente desacoplados y se apoyan en el protocolo HTTP.

En resumen, en mi opinión, no hay para tanta historia de si dejamos SOA para ir a los APIs o similar… según yo lo veo, y considerando únicamente como APIs a aquellos expuestos como REST o SOAP… un API (bien hecho) es una forma de uso de SOA, es decir, una caso concreto de implementación de servicios.