Hoy en día, encontrar una API externa que nos permita mejorar la calidad de nuestro servicio es muy fácil. Cada día mas empresas ponen a disposición APIs. Problema: numerosos desarrolladores/CTOs empiezan la integración, ¡mientras que debería de ser la ultima etapa! Antes de eso usted tiene que determinar si la calidad de la API basta. Aquí esta como hago yo. Espero que todo ello ayudara a otros CTOs y desarrolladores.
Calidad de los datos
Muchas APIs proveen datos que le permiten enriquecer su propio sistema (no es el caso de todas las APIs por supuesto, Stripe no es una API de enriquecimiento por ejemplo). Es indispensable que se asegure de la calidad de estos datos. Va a tomarle mucho tiempo, ¡y ya sé que no le gustan las pruebas! Yo tampoco, pero no puede evitar la creación de un escenario de prueba riguroso aquí. Si se da cuenta de que la calidad de sus datos no esta bastante buena, solo dos semanas después de haber terminado su integración, se arrepentirá…
Documentación
Recientemente me encontré una API que proveía datos de alta calidad (mucho mejor que lo que la competencia proponía para mí), pero su documentación era… ¡una pesadilla! En realidad no había documentación. Además la API no respetaba todas la convenciones REST. ¿Cómo puede lograrlo integrar una API externa si los códigos de error no están correctamente documentados? Entonces la única solución que queda es probar mucho la API para entender su funcionamiento. La ingeniería inversa puede ser graciosa pero necesita mucho tiempo. Recuerde que en lo que concierne una API no tiene repositorio GitHub a explorar ya que el código fuente no esta disponible… Una mala documentación le hace perder mucho tiempo al dev y trae sorpresas desagradables a medio plazo.
Bibliotecas
¿Es posible integrar la API gracias a una biblioteca disponible en su lenguaje favorito? Como desarrollador Python y Go siempre estoy encantado cuando me encuentro una API que ofrece una lib Python (sé que puedo olvidar Go por el momento). Le puede hacer ganar mucho tiempo, pero ante todo asegúrese de que la biblioteca esté madura y que cubra todas la funcionalidades de la API (no siempre es el caso).
Notoriedad de la empresa
La notoriedad puede ayudarle a aclarar su elección y evitar las sorpresas desagradables con su API en el futuro. Por “sorpresa desagradable” entiendo interrupción de servicio, regresión, o incluso la suspensión definitiva del servicio… Puede en parte evitar estas trampas preguntándose lo siguiente:
- ¿Esta API es popular en Internet (en general si encuentra poca información, huya)? ¿Encuentra muchos artículos/tutoriales que hablan de la API? Estos artículos son elogiosos?
- ¿Empresas populares la utilizan?
- Si la empresa ha desarrollado bibliotecas dedicadas, ¿estan evaluadas de forma positiva en GitHub? ¿Los problemas reportados en GitHub están tratados con regularidad?
- ¿Hubieron actualizaciones recientes de la API o la ultima actualización tuvo lugar hace mucho tiempo?
Soporte técnico
Asegúrese de que alguien responda a sus preguntas rápidamente por email cuando usted encuentra un problema y que la respuesta es relevante. Si vive en Europa y la API esta proveída por una empresa americana, asegúrese de que el desfase horario no sea un problema.
Respeto de las convenciones
Para mi, las APIs serias hoy tienen que ser RESTful. Si la API que le gusta no respeta la convenciones REST, pues desconfíe de esta API. Sin embargo tenga presente que el estándar REST no es perfectamente claro y que cada API puede tener sur propia variante (códigos HTTP, codificación de las consultas POST, …). A pesar de todo, tiene que leer la documentación atentamente y asegurarse de que no nota cosas demasiado originales. Originalidad le ralentizara…
Precio
Claro el precio es muy importante. Pero cuidase, la tarificación de una API no siempre es fácil de entender. ¿Va a pagar cada mes por un numero ilimitado de consultas? ¿Pagar por cada consulta? En este segundo caso, ¿va a pagar dos veces por dos consultas idénticas (caso de una API de enriquecimiento)?, ¿o la segunda consulta será gratis? ¿Va a pagar por una consulta que no retorna ningún resultado (HTTP 404)? Asegúrese de que lo entiende bien todo.
Calidad de servicio (QoS)
La calidad de servicio importa mucho. Su meta es trabajar con una API la mas rápida posible y con pocas interrupciones. Lamentablemente no se trata de desempeños fáciles de probar. En efecto la calidad de servicio cambia mucho con el tiempo, y numerosas APIs ofrecen dos niveles de QoS diferentes según utiliza la versión gratis o pagada… A veces incluso puede elegir diferentes suscripciones con diferentes tiempos de respuesta.
Soporte de las consultas paralelas
Según la manera de integrar la API, quizás tenga ganas de acelerar las cosas consultando la API con varias consultas simultaneas en lugar de la configuración secuencial clásica. Yo utilizo Golang con ese fin. Pero cuídese: muchas APIs no soportan las consultas paralelas y cuando las soportan imponen sistemáticamente una limite. En este caso asegúrese de pedir que es esta limite (no siempre esta mencionado en la doc) y adapte su programa.
Este articulo sera un buen memo para mi, ¡espero que para usted también!