Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo una API con fugas puede acabar con su negocio

 Con las brechas de API que surgen cada semana, las pruebas son más cruciales que nunca


Hay una tendencia a creer que si algo funciona, está bien. Como dice el refrán, "si no está roto, no lo arregles". El problema con esto es que, particularmente cuando se trata de API, no siempre es fácil detectar si algo está roto o no.

En nuestra Cumbre de Plataformas 2017, Patrick Poulin de API Fortress hizo la siguiente pregunta: "¿Pones el mismo nivel de esfuerzo en probar tu API que para probar sitios web y aplicaciones?" Si nos basamos únicamente en números, la respuesta es que la mayoría de la gente no lo hace.

Patrick cita un estudio de Smartbear que encontró que menos del 10% de los problemas de API se resuelven en 24 horas y el 25% de los problemas permanecen sin resolver durante 7 días o más.

A continuación, veremos por qué ese es el caso; vale la pena señalar de inmediato que, como verá en los tres ejemplos del mundo real de "API con fugas" proporcionados por Patrick a continuación, generalmente se reduce a la ignorancia de posibles problemas de ruptura de API y no negligencia. Descubramos lo que normalmente se omite y analicemos tres formas en las que estos problemas pueden dañar su negocio y su reputación.

Vea a Patrick Poulin presente en la Cumbre de la Plataforma Nórdica de APIs 2017:

Diapositivas

El tiempo y el uso son factores

La respuesta más fácil a la pregunta de por qué persisten los errores de API es que, a menos que estemos hablando de una empresa que se ocupa exclusivamente de API, los desarrolladores suelen hacer malabarismos con el mantenimiento de API con otros proyectos.

Si la propiedad de una API y los problemas relacionados con ella están mal definidos, los desarrolladores pueden inclinarse a pensar que alguien más será quien solucione el problema. Y eso si miran la API con la suficiente frecuencia para detectar el problema en primer lugar.

Luego está el hecho de que muchas API son utilizadas con poca frecuencia por un pequeño número de personas, a veces solo por unas pocas dentro de la propia organización. En otras palabras, simplemente puede que no haya suficientes usuarios activos para identificar y llamar la atención sobre el problema.

Pero hay un problema con esta explicación. Sabemos por el estudio vinculado anteriormente que incluso las empresas de API dedicadas con productos que tienen decenas de miles de usuarios no están exentas de responder con lentitud, por lo que debe haber otros problemas en juego aquí ...

Lea también: Pruebas y monitoreo de API con API Fortress

Defectos ≠ Rotos (pero dañan la confianza)

Patrick dice en su charla que “notamos cuando una API está inactiva. No nos damos cuenta cuando hay un poco de fugas ". Eso es cierto no solo para las API sino para la tecnología moderna en general; nos enojamos cuando un dispositivo no se conecta a Internet en absoluto, pero generalmente estamos felices de descartar el rendimiento lento de nuestro enrutador, el clima o incluso que "todos en el edificio deben estar en línea en este momento" ... al menos por un poco de tiempo.

Aunque la mayoría de los desarrolladores de API tienen en cuenta el rendimiento y el tiempo de actividad al evaluar la calidad de sus API, Patrick justifica considerar la precisión junto con estos factores. En otras palabras, que todas las funciones de la API están haciendo exactamente lo que se supone que deben hacer en un período de tiempo razonable.

El primer ejemplo que da en su charla es un importante editor de libros que proporcionó un tiempo de actividad autoinformado del 99,87% en su API afiliada. Resultó que, en una inspección más cercana, su tiempo de actividad real era del 97,3% porque había cientos de errores 404 que regresaban.

La razón de esto fue que su administrador de API estaba almacenando en caché los puntos finales del producto y, cada vez que se actualizaba la base de datos, ese punto final sería incorrecto durante algunas horas a la semana. La solución aquí fue probar en la implementación, lo que acercó su tiempo de actividad a lo que habían estado informando originalmente.

Sabemos que el tiempo de inactividad es un factor importante cuando se trata de generar confianza con los consumidores, y el 18% de las empresas dice que las interrupciones de TI tuvieron un impacto "muy perjudicial". en su reputación. Si los usuarios no pueden confiar en que su API funcione de manera confiable, buscarán en otra parte.

Sin embargo, como veremos en los ejemplos a continuación, los problemas de API no detectados también pueden tener un impacto financiero más inmediato ... y no solo en su negocio.

Relacionado: más de 10 herramientas de supervisión de API

Las API defectuosas perjudican los resultados finales

Patrick también describe el trabajo de su empresa con Etsy y cómo se estaban perdiendo ventas por valor de hasta 75.000 dólares al día . Las pruebas realizadas en base a su propia documentación de API encontraron que 3,000 productos carecían de la categorización adecuada porque un campo estaba marcado como opcional en lugar de obligatorio.

Como resultado, estos productos no se pudieron encontrar usando la navegación de nivel superior, y mucho menos a través de aplicaciones externas que usan su API. Si no aparece en la búsqueda, las ventas son menores y el recorte para Etsy es menor.

El ejemplo final que proporciona Patrick es una empresa de impresión bajo demanda que estaba utilizando la API de una empresa de imágenes de archivo y no reportó ingresos en un miércoles en particular. Miércoles negro, por así decirlo. Un pequeño cambio en el desarrollo estructural de la empresa de imágenes de stock significó que la integración particularmente estricta de la empresa de impresión bajo demanda ya no podía obtener la información que necesitaba.

¿Lo realmente aterrador? Fue un contador quien captó el problema, en lugar de un desarrollador de uno de los equipos involucrados. Una vez más, esto demuestra lo fácil que es que los problemas no se detecten cuando nadie sabe (o se molesta en) buscarlos. Por cierto, el resultado de la situación fue que la compañía de imágenes de stock comenzó a probar su API en la implementación de manera mucho más estricta.

Claramente, perder ingresos es algo malo. Pero para una empresa de API, donde facilitar los procesos con otras empresas es clave, las recomendaciones a menudo provienen de reseñas positivas o del boca a boca. Las repercusiones de tales errores, entonces, también podrían causar una pérdida de negocios potenciales. Si tiene suficientes días como el miércoles negro, pronto descubrirá que su API no tiene ningún usuario.

Consulte: 9 tipos de pruebas para realizar en sus API

Pensamientos finales

Patrick señala al principio de su charla que el hecho de que algo esté sucediendo no significa que esté funcionando correctamente. Hemos visto anteriormente lo cierto que puede ser eso. Más adelante, hace dos declaraciones interrelacionadas que resumen el enfoque ideal para las pruebas y las API:

  1. “Hemos llegado a ese punto de madurez ahora que la prueba tiene que ser tomado en serio.”
  2. "Todos pensamos que no se puede probar una API con mucha facilidad, y eso ya no es cierto".

Al proporcionar ejemplos de herramientas y productos de monitoreo de API como SmartBear, API Fortress, Runscope y Postman, destaca el hecho de que incluso los empleados no técnicos pueden colaborar con las pruebas de API.

Según lo que hemos visto anteriormente, los siguientes pasos son vitales para prevenir una API con fugas:

  • Cree y ejecute pruebas de integración, o pídale a otra persona que lo haga
  • Pruebe la implementación más a fondo, es decir, las pruebas deben ser detalladas, en lugar de sueltas
  • Anime a sus usuarios a ponerse en contacto sobre cualquier problema que encuentren
  • Pruebe todo el ciclo de vida (vea la diapositiva a continuación), incluido el entorno en vivo

Patrick enfatiza lo importante que es probar los problemas de la API durante todo el ciclo de vida del desarrollo.

Regresemos al ejemplo mencionado anteriormente en esta publicación: los usuarios de un determinado sitio web o aplicación solo culparán el rendimiento lento a problemas internos (por ejemplo, ruido de señal que interfiere con su enrutador, alguien más en la casa descarga archivos, etc.) durante mucho tiempo antes de que lo hagan. empezar a intentar echar la culpa a otra parte.

Por lo general, comenzarán con el propietario del sitio y / o el proveedor de servicios de Internet (o, en nuestro caso, el proveedor de API). Si no pueden solucionar el problema en un período de tiempo razonable, es muy probable que abandonen el sitio / ISP para siempre y naveguen a otro lugar.

La mayoría de las API están diseñadas para reducir la fricción y facilitar la vida de sus usuarios. Si una API no está haciendo eso debido a una falla, por menor que pueda parecerle, entonces corre el riesgo de que los usuarios busquen una forma alternativa de hacer el trabajo.

Los errores más comunes que no se detectan en las API nórdicas

Publicar un comentario

0 Comentarios