De como la computación en la nube se basa en APIs y éstas, en contratos. Y de como el establecimiento de un contrato entre el consumidor y el proveedor es el primer paso para la construcción de un API (y de cualquier aplicación).

¿Qué tienen en común un barco inglés del siglo XVI y el interfaz de un servicio web? Hagamos un poco de historia…

Inglaterra 1547

“Considerando que, desde tiempo inmemorial, fue de uso corriente entre los comerciantes de este reino y de otras naciones, que cuando emprendían un negocio sobre todo en los países lejanos, dar alguna cantidad de dinero a otras personas, ordinariamente una sociedad, para hacer asegurar sus bienes, mercancías, buques y otras cosas expuestas a los riesgos, sino totalmente por lo menos en parte, en la proporción y de la manera en que los asegurados y los aseguradores podrán convenir, cuya convención comúnmente llamada -Póliza de Seguros-, hace que la pérdida de un buque no vaya seguida de la ruina de los que en el mismo tengan interés.”

<https://www.universales.com/acerca-de/la-historia-del-seguro/>

El concepto de contrato es tan antiguo como el seguro mismo, primero de manera verbal y luego por escrito. Cuando se contrata un seguro, los acuerdos a los que se llegan entre las dos partes se plasman en un contrato que es la póliza de seguros. Ahí se indica a qué se compromete cada parte y cómo va a proceder cada uno mientras la póliza tenga vigencia.

Estados Unidos, primeros años de la década de 2000

Contratos de servicio estandarizados: forma parte de la esencia misma de un servicio. Para que se considere un servicio,  su interfaz de entrada/salida (su contrato con el cliente) tiene que estar explícitamente declarado. Los campos  que forman parte de este interfaz deben estar correctamente tipados y ser conocidos.

https://andreshevia.com/2010/02/27/principios-de-soa/

Así pues, si estamos tan acostumbrados a manejar contratos cuando contratamos un seguro… ¿por qué no hacer lo mismo cuando hacemos software?. Un software está bien diseñado cuando le dice al resto del mundo qué se puede esperar de él, cómo se le puede llamar y con qué parámetros, qué va a hacer con esos parámetros y qué otros parámetros va a devolver en esta llamada. A todos los efectos es un contrato, que se puede recoger en un documento escrito, por el que el servicio se compromete con sus clientes.

¿Qué aporta el contrato en los servicios T.I.?

El contrato de los servicios tiene innumerables ventajas:

  1. Estabilidad:
    un contrato no se puede cambiar de manera unilateral. Las dos partes tienen que estar de acuerdo en esto. En un servicio I.T. ocurre lo mismo. Como proveedores tenemos que garantizar que no cambia su contrato, y si lo hace, que lo haga en términos que se denominan «retro-compatibles»… es decir, que el cliente no se vea afectado (por ejemplo, añadiendo un nuevo campo de entrada opcional).
    Si el contrato va a cambiar de una manera que no es compatible, es necesario «firmar» otro contrato… es decir, si ahora mismo tenemos la versión 1 del contrato y creamos una nueva versión, la 2, tenemos que comunicarlo a los clientes y darles tiempo para que se puedan adaptar. Normalmente ambas versiones del contrato convivirán el tiempo suficiente hasta que la versión antigua sea retirada.
  2. Desacoplamiento:
    ¿Un cliente de una póliza de seguros tiene que conocer los algoritmos que permiten a la compañía aseguradora mandarle una grúa? Pues no… lo que le interesa es saber cuánto tiene que esperar hasta que llegue la grúa. Esto permite a la aseguradora mejorar sus procesos internos sin tener que informar a todos sus clientes (lo cual sería absurdo). Dicho de otro modo, al cliente lo que le interesa es saber que su proveedor de servicios respectará su contrato y le dará las prestaciones que están recogidos en él…. Con los servicios pasa lo mismo.
    Los detalles internos del servicio permanecen ocultos y sólo «expone» el contrato, que es conocido por todos… a todos los efectos, un servicio con un contrato bien definido es un caja negra, lo que le permite evolucionar internamente sin afectar a los clientes.
  3. Productividad en el desarrollo de las aplicaciones:
    El desarrollo de una aplicación informática es un proceso muy complejo donde intervienen muchas personas, incluso muchos equipos. Normalmente, por motivos de especialización técnica, existe un equipo que se encarga de la parte cliente (el frontal), mientras que otro equipo (u otra empresa) se puede ocupar de los servicios de negocio (lo que podemos denominar la aplicación «Backend»).
    Pues bien, si no tenemos definido el contrato del API que el equipo de Frontal va a consumir y que el equipo de Backend va a proveer nos encontraremos con bloqueos absurdos que incrementarán los tiempos y el coste de nuestro proyecto. No puede ser que el equipo de Frontend tenga que esperar a que el del backend acabe, para eso están… oh sorpresa!, los contratos de los servicios.
    Si el primer paso del proyecto es definir estos contratos, los dos equipos pueden trabajar de manera independiente y cuando acaben hacer las pruebas integradas con la confianza de que el otro equipo habrá respetado el contrato, el nexo de unión entre las dos partes… si no lo se hace así el resultado puede ser catastrófico.
  4. Contract first:
    El uso de contratos tiene una importancia crítica en el desarrollo de software, de cualquier tipo de software. Tanto es así, que las buenas prácticas recogen el concepto de «contract-fist», lo que viene a decir que lo primero que hay que hacer es el contrato y luego el servicio, no al revés.
    Por desgracia, se ven demasiados casos del tipo «contract-last» en el que primero se hace el software y luego se genera el contrato con el interfaz de parámetros de entrada/salida de manera automática. Quizás porque es la única forma de hacerlo que muchos equipos han visto.  Si este es tu caso, por favor, cambia a un enfoque «primero el contrato» porque tiene infinidad de ventajas:
    • Conseguimos la productividad de los equipos y evitamos bloqueos innecesarios como hemos visto en el punto anterior
    • Nos aseguramos que el contrato está bien construido y no se ve «contaminado» por el lenguaje de programación que estamos usando (la generación del contrato a partir del código produce resultados muy mejorables)
    • Existen herramientas de productividad que generan un esqueleto de la aplicación a partir del contrato
       

Conclusión

Los armadores del siglo XVI sabían que si no querían irse a la ruina si su barco se iba a pique tenían que tener un contrato de seguros. No sé cómo se llegan a firmar estos contratos pero lo que si sé es que cuando esta firma se hace en el siglo XXI se hace a través de otro contrato, el contrato del servicio web de contratación de seguros.

Un consejo, cuando te hablen de  una aplicación o de un servicio, pide primero que te enseñen el contrato… y asegúrate que está bien definido y que está validado. Sin ninguna duda, el contrato es el cimiento de cualquier aplicación.