Todo lo que puede fallar usando Web Services

1. Documentación

Suele ser lo primero a buscar cuando usamos un WebService y es vital que sea fiable.

Por nuestra experiencia, los WebService documentados con la especificación Swagger/Open API suelen ser una garantía de éxito.

2. Entornos de prueba

O no existen, o la implementación no coincide con la de producción. Es importante que el proveedor nos lo deje claro para saber a que nos vamos a enfrentar al poner en producción. Los ejemplos ya sea en la documentación o fuera de ella son críticos para poder implementar con garantías.

3. Comunicación con el WebService

Existen muchos elementos intermedios hasta el propio WebService, es importante asegurarse que podemos cumplir todos y funcionan correctamente. Acceso por proxy, certificado ssl válido, elementos intermedios de comunicación, etc.

4. Codificación, Hashs y saltos de línea

En algunos servicios web se requiere calcular el hash, el encode, base64 de un valor. Debemos tener muy en cuenta la codificación previa de ese dato. Podemos perder muchas de horas por ver que te piden un hash de una cadena de texto utf-8 o el base64 de una cadena latin1. En la codificación está el diablo. Los saltos de línea /r/n o /n también pueden darnos unos buenos disgustos. Es importante tener claro como requiere el WebService la información.

5. Buscar los límites

Una vez lo tengamos desarrollado y mientras nos dejen un entorno de pruebas, debemos buscar los límites, TODOS los límites. Campos enormes, valores numéricos negativos y muy grandes, valores vacíos, etc. Debemos encontrar los límites en este momento y no dentro de un año en producción cuando un usuario mande datos un poco "raros". Recordar que la realidad supera la ficción. También probar la codificación de caracteres extraños (por ejemplo: camión español) ayuda a detectar en pruebas si lo que le enviamos al WebService es válido.

6. Conservador en lo que hace, sea liberal en lo que acepta de los demás

Si aplicamos el principio de robustez de Postel en el consumo de API, debemos ser tolerantes respecto a lo que nos puede llegar del servicio web y aceptar que puede llegar variaciones. Pero cuidadosos en lo que hacemos o enviamos a dicho servicio y ser conservadores en como informamos al usuario o nuestro sistema de los fallos. Este principio nos guiará a tener una comunicación robusta con los WebService que consumimos.

7. Registra todo

En producción las cosas fallan, debemos tener log de esos fallos, tanto lo que nosotros enviamos como lo que hemos recibido del WebService, eso nos ayudará a evaluar el problema y poder entender lo sucedido para que no vuelva a pasar.

8. Usar herramientas que te ayuden

Existen múltiples herramientas que te pueden ayudar durante todo el proceso de desarrollo, despliegue y producción. Postman es una de ellas, básica para el desarrollo y pruebas del WebService antes de ponerte a programar una sola línea. Una vez en producción monitorizar el WebService con herramientas como zabbix, te permitirá saber si todo funciona correctamente antes que los usuarios puedan detectar un fallo.