Header Ads Widget

Ticker

6/recent/ticker-posts

7 prácticas recomendadas para las zonas de pruebas de API

 

Proporcionar un entorno de prueba dedicado para su API es una forma segura de mejorar la experiencia del desarrollador y fomentar las suscripciones. De hecho, muchos de los proveedores de API más grandes del mundo, desde PayPal hasta Salesforce, ya lo hacen en forma de un entorno de pruebas de API .

En este artículo, analizaremos siete prácticas recomendadas para aprovechar al máximo su entorno de pruebas API . Pero primero, ¿qué es exactamente un recinto de seguridad de API y cuáles son los beneficios de tener uno?

¿Qué es una API Sandbox?

Un recinto de seguridad de API es un servicio que emula el comportamiento de una API de producción. Si bien no existen definiciones estrictas, creemos que los entornos sandbox se diferencian de las API simuladas en que están dirigidos principalmente a desarrolladores externos. Permiten realizar pruebas sin riesgos y sin costo de una API, lo que las convierte en una parte crucial de una estrategia de API orientada a DX.

Beneficios

Los entornos sandbox de API tienen numerosos beneficios, tanto para los desarrolladores como para los propietarios de API. Los desarrolladores se benefician de poder probar de forma continua y agresiva integraciones nuevas o actualizadas, sin preocuparse por acumular una factura considerable (en el caso de una API paga) o que se bloqueen sus solicitudes. Además, los entornos sandbox suelen estar disponibles para cualquier desarrollador registrado, lo que los convierte en la forma perfecta para que los posibles clientes desarrolladores prueben una API antes de comprometerse con un plan pago.

Ambos factores conducen a una mejor experiencia del desarrollador, durante y después del proceso de incorporación, lo que tiene una ventaja definitiva para los propietarios de API. Además, la capacidad de "probar antes de comprar" ayuda a aumentar tanto los registros como las suscripciones pagas. Por último, pero no menos importante, ejecutar un entorno de pruebas de API reducirá la tensión en la API de producción más importante.

Ejemplos

Siete sugerencias cortas y dulces para el éxito de la zona de pruebas

Si está buscando lanzar u optimizar su caja de arena de API, existen bastantes mejores prácticas que pueden maximizar sus resultados. En particular, hemos identificado siete sugerencias a las que debe seguir:

1. Aísle su caja de arena

Asegúrese de que su entorno de pruebas API esté aislado del resto de su plataforma. Una caja de arena debería permitir a los desarrolladores simular el comportamiento de su API; Sin embargo, no debería permitir la interacción directa con su plataforma de la misma manera que lo haría una API de producción. Si no tiene cuidado con su sandbox, podría afectar los sistemas de producción, exponer datos reales o contribuir a la confusión de facturación, por lo que es mejor construir su sandbox desde cero en un entorno aislado.

2. Proporcionar acceso gratuito

Permita que los desarrolladores accedan a su caja de arena de forma gratuita . Después de todo, el principal atractivo de la prueba en contra - o probar a cabo - una caja de arena es que es gratis! Esto es especialmente cierto para los posibles clientes desarrolladores que, de lo contrario, podrían necesitar pasar por un largo procedimiento de aprobación para obtener la aceptación corporativa incluso para las pruebas más asequibles.

Sí, existen costos asociados con el alojamiento de una caja de arena de API ... pero califíquelo como una parte crucial de la adquisición de clientes y DX. Si no puede justificar los costos de un sandbox ilimitado, considere otorgar a los desarrolladores un número limitado de créditos de sandbox gratuitos al registrarse, lo que reducirá significativamente el rendimiento.

3. Recrear el comportamiento de producción

Esfuércese por hacer que su caja de arena sea lo más cercana posible a la realidad. Para los desarrolladores, es muy valioso saber que lo que prueban con la zona de pruebas se comportará de manera idéntica con la API de producción. Sin saber esto, los desarrolladores se verán obligados a ejecutar sus integraciones a través del segundo conjunto de pruebas con la API real, frustrando un poco el propósito de una caja de arena.

Si su API de producción admite POSTsolicitudes, entonces admita POSTsolicitudes en la zona de pruebas. Si su API de producción implementa la paginación, implemente la paginación en la zona de pruebas. Es muy probable que base su sandbox en una especificación de API, así que preste mucha atención a las áreas en las que su especificación podría fallar .

4. Recuerde la autorización

En particular, ¡no se olvide de los métodos de autorización o autenticación utilizados por su API de producción! Este aspecto del comportamiento de la API, que también se excluye con frecuencia de las especificaciones de la API, merece un reconocimiento especial, ya que es un punto débil tan común para los desarrolladores. Por supuesto, debe tenerse en cuenta en su caja de arena, ya sea que confíe en claves API o tokens de acceso.

5. Cuenta para pasarelas o proxy

Al construir su sandbox, considere las implicaciones de cualquier puerta de enlace o proxy que se encuentre frente a su API de producción. Claro, es posible que no sean parte de la API en sí, pero aún pueden afectar mucho las integraciones de los desarrolladores. Quizás el mejor ejemplo de esto es la limitación de velocidad : a menudo implementada en el nivel de la puerta de enlace, puede afectar significativamente el comportamiento de las integraciones.

Depende de usted decidir si y cómo dar cuenta de estos problemas. Con la limitación de velocidad, algunos propietarios de API limitan los sandboxes exactamente como lo hacen con las API de producción, mientras que otros, como Salesforce, aumentan enormemente los límites de sandbox para permitir pruebas más extensas. El autor personalmente favorece el enfoque adoptado por Evernote: los límites para la producción y las API de sandbox se activan al mismo tiempo (después de una cierta cantidad de llamadas por hora), pero los usuarios de sandbox solo tienen una tasa limitada de 15 segundos , y no para el resto de la hora.

De esta manera, los desarrolladores pueden probar y manejar la excepción de límite de frecuencia sin tener que esperar hasta que finalice el intervalo de una hora para reanudar la interacción con la API.

6. Revise el uso de la zona de pruebas

Si los recursos lo permiten, tómese el tiempo para revisar cómo se usa periódicamente su entorno de pruebas API. Por un lado, mirar los registros de la zona de pruebas puede ayudarlo a identificar patrones de uso inesperados que puede admitir. Más importante aún, observar los errores que ocurren con frecuencia puede resaltar los puntos débiles comunes, especialmente en la experiencia de incorporación, que mejorará la retención cuando se solucione.

7. Considere una simulación del caos

Por último, pero no menos importante, los programas de API maduros en industrias de alto riesgo deberían considerar la posibilidad de crear una simulación del caos junto con su caja de arena de API diaria. Acuñado por el arquitecto de Microsoft Gareth Jones, el simulacro del caos es una virtualización de API que encarna la variabilidad a propósito. El objetivo de un simulacro de caos es permitir que los desarrolladores codifiquen contra todo tipo de comportamiento de API extraño y maravilloso, para que puedan estar seguros de que sus integraciones sobrevivirán en todas las circunstancias.

Pensamientos finales

Acabamos de revisar siete formas de aprovechar al máximo su entorno de pruebas API. Siga estos consejos y obtendrá un entorno que permite realizar pruebas precisas y prácticas de su API, entre otros beneficios. Ahora, ¿de qué otra manera puede mejorar la experiencia del desarrollador para su API?

Publicar un comentario

0 Comentarios