Análisis e-conomía

Los 10 errores más comunes al ofrecer una API

Twitter fue  de los primeros en saber lo que sucede cuando recibimos más tráfico de nuestra API que de nuestra página. Ahora tiene más de 65 millones de tweets al día, y la mayoría provienen de servicios que utilizan la API. Twitter ha hecho varios cambios para mejorar su API  y ha enseñado a  otros  los errores en los que no deberían caer. Pero aún queda mucho por aprender , os lo enseñamos…

Considerando esto, hemos pedido a un grupo de desarrolladores y proveedores que nos ayudaran a hacer una lista  de los 10 errores comunes que se cometen al desarrollar una API. Con suerte, esta lista ayudará a tener una idea básica sobre las decisiones que debemos evitar.

Nuestro grupo de expertos incluye a Adam DuVander, director editorial de Programmable Web; Mike Pearce, un desarrollador británico; Clay Loveless de Mashery’s y Sam Ramji de Sonoa Systems.

1. Asumir que todo saldrá según lo planeado

“Las bases de datos fallan, las dependencias del backend hacen que el funcionamiento sea más lento, y alguien no escapa los datos de salida correctamente. ¿El resultado? Un desagradable stacktrace encima de la carga de datos de la API, lo que en algunos casos puede incluir credenciales de bases de datos de producción.

Solución: antes del lanzamiento es recomendable eliminar un par de dependencias para ver como reacciona la API. Para los desarrolladores es preferible tener un mensaje de error (en JSON/XML) predecible que una carga de datos inválida por sorpresa.

Fuente: Clay Loveless

2. Community Management deficiente

“Algunas veces observamos que los proveedores esperan que la API atraiga a los desarrolladores por sí sola. Es necesario un buen servicio y es crucial comunicar a los desarrolladores qué es lo que ofrecemos. Además, es fácil olvidarse de la necesidad de un buen community manager, pero esto puede suponer la diferencia entre el éxito y el fracaso de una plataforma. Cuando se obtiene la atención de los desarrolladores hay que mantenerla siendo comunicativo y ofreciendo ayuda, se debe de tratar a los desarrolladores como socios”

Fuente: Adam DuVander

3. No anticiparse escalado  del servicio de la API.

“Lo que hacen las API es ofrecer nuestro negocio a la escala de la red entera. ¿Pero qué sucede si se llega realmente a esta escala? Si nuestra popularidad crece estrepitosamente ¿se escalará la revisión manual del registro de usuarios? ¿Los procesos de revisión y responsabilidad obstaculizarán el acceso a un subconjunto de datos? El control es menos importante cuando la API tiene poco uso, pero cuando el volumen de transacciones aumenta significativamente, las API comienzan a ser importantes en términos financieros y legales. Existe el riesgo de morir de éxito por falta de procesos escalables”.

Fuente: Sam Ramji

4. Poner la API bajo el dominio del sitio.

“Caso práctico: twitter.com ahora dirige a api.twitter.com para la API. El resultado es que ellos pueden escalar el sitio web y la API independientemente cuando sea necesario. Nunca he oído a nadie lamentarse por haber dividido el tráfico de la API y el del sitio principal, y prácticamente cualquiera que no lo haga desde el principio acaba deseando haberlo hecho y acaba atravesando un lento y doloroso proceso de migración de los desarrolladores hacia la nueva ubicación de la API”.

Fuente: Clay Loveless

5. Falta de tests en el “Mundo Real”.

“A menudo podemos notar qué APIs se han utilizado en el mundo real antes del lanzamiento y cuáles no. Por ejemplo: una API que hace un listado sobre la información de un objeto pero necesita hacer una segunda llamada para obtener más información acerca de ese objeto. Si tu API necesita dos llamadas para averiguar ‘todo lo que hay que saber’ te odiarás a ti mismo… y tus desarrolladores también.

Hay que construir un par de aplicaciones de referencia que puedan hacer algo útil, aunque sea insignificante. Rápidamente se tendrá una idea de lo bien que funciona la API. Si no se ha construido el sitio web sobre la API, hay que considerar hacerlo o al menos considerar como sería si estuviese construido así. Si la API no puede reproducir el sitio web, necesita arreglos”.

Fuente: Clay Loveless

6. No anticiparse al mal comportamiento

1)Mal comportamiento táctico

Un código de cliente ineficiente puede llamar una API con mucha frecuencia, lo que ocasionará un ataque DDoS accidental.

Las API pueden recibir ataques a través de datos de JSON o XML que se transmitan como parámetros o adjuntos.

Las técnicas de ataque pueden incluir inyecciones SQL, bombas XML y scripts de shell, así como los típicos ataques de ingeniería social y spoofing.

2) Mal comportamiento “en escala”

Cuando el servicio es pequeño y hay cientos de usuarios, puede que sólo haya dos maliciosos. Esto se puede ser resolver manualmente utilizando reglas de firewall basadas en las direcciones IP.

Cuando el servicio está escalando a cientos de miles de usuarios, puede haber miles de ellos que sean maliciosos. Éstos estarán solicitando altos niveles de “falsa” demanda en el servicio y no podrán ser eliminados manualmente sin contratar mas empleados dedicados exclusivamente a este problema.

Para mitigar esto ¿aplicamos límites de cuota  a todos los usuarios, lo que reduce el valor del servicio para los usuarios normales? ¿O buscamos encontramos un modo de aplicar normas que de forma natural separen las diferentes pautas de uso?

Fuente: Sam Ramji

7. No hacer pruebas de Caja Negra

“Muchas API no se prueban antes de su lanzamiento, y la gran mayoría de las que pasan por mecanismos de testeo suelen hacerlo de manera automatizada. Solo a unas cuántas se les realizan pruebas completas de Caja Negra que pueden ser llevadas a cabo entre releases. Las pruebas por unidades están bien pero si el último push incluye un cambio en la configuración del servidor web, será interesante hacer una batería de pruebas completa para validar esos cambios”.

Fuente: Clay Loveless

8. No reconocer las API como la línea de negocio principal.

“Las compañías que triunfan en la nueva economía web reconocen que las API son la línea de negocio básica, y una ruta esencial para llegar a clientes y socios. Los negocios de medios audiovisuales, de venta al menor y en Internet a menudo reciben un 50% de su tráfico de la API, y las empresas deberían tratarla como un producto”

Fuente: Sam Ramji

9. No llevar a cabo una gestión horizontal

“Como en cualquier otro proyecto, los negocios y la tecnología deben estar alineados para un fin común, lo que incluye haber entendido y documentado los objetivos y recompensas. Se debe tener en cuenta qué objetivos de alto nivel se están cumpliendo y qué lugar ocupan para los diferentes departamentos de marketing, atención al cliente e ingeniería”.

Fuente: Sam Ramji

10. Errores de Tunneling

“Los errores específicos que se ven normalmente son: tunneling de errores (enviar de vuelta un código de respuesta “200OK” incluso si el cuerpo de respuesta describe un error); tunneling de GET/POST (enviar todas las solicitudes a través de GET o POST e ignorar los otros verbos PUT, DELETE, etc.); y tipos de contenido (no permitir al consumidor especificar el tipo de contenido que desea aceptar).

La mayoría de las grandes empresas lo hacen bien. Amazon es un buen ejemplo, sin embargo Flickr no. No obstante, la mayoría de los proveedores de API pasan por alto cuestiones más complejas como los hipermedios como motor del estado de la aplicación e ignoran las funciones de almacenamiento en caché. De cualquier forma se puede utilizar una API de forma adecuada sin todo esto, es el tunneling incorrecto lo que acabará incapacitando al desarrollador y a los clientes”.

Fuente: Mike Pearce

Sobre el autor de este artículo

Editorial RWWES