Header Ads Widget

Ticker

6/recent/ticker-posts

Sugerencias y herramientas para depurar API

 

Sugerencias y herramientas para depurar API

Benjamin Franklin dijo una vez que "en este mundo no se puede decir nada como seguro, excepto la muerte y los impuestos". Para el desarrollador de software, el dicho debe modificarse para que diga "excepto muerte e impuestos, y errores de software ".

Es un hecho lamentable que la propia naturaleza del desarrollo de software, especialmente en los entornos de colaboración populares entre los codificadores y las empresas de hoy, hace que los errores de software sean inevitables. A medida que las API y los sistemas que las impulsan se han vuelto cada vez más complejos, también lo ha hecho el código subyacente que lo impulsa todo.

Entonces, ¿cómo deberían los desarrolladores lidiar con estos errores? Hoy, vamos a discutir algunos consejos y herramientas no solo para detectar errores , sino para tratarlos una vez descubiertos, y cómo evitar que los errores se conviertan en un dolor de cabeza.

Fallos de soporte interno

Una de las causas más comunes de fallas de API es una falla en la acción y decisión de codificación interna. Los desarrolladores generalmente tienden a implementar soluciones específicas de dependencia o de protocolo para problemas comunes; después de todo, ¿por qué reinventar la rueda? Y la mayoría de las veces no, estas soluciones están bien, pero a veces, pueden ocurrir errores cuando las diversas dependencias en las que se basa un sistema se citan incorrectamente o se implementan localmente. Aquí hay algunas formas de evitarlo:

Verifique que HTTP / 2 esté implementado correctamente. Las
fallas pueden ser muy básicas. Por ejemplo, la falta de implementación adecuada de HTTP / 2 puede tener resultados desastrosos, provocando fallos en la negociación cliente-servidor y provocando tiempos de espera debido al aumento de la latencia. Peor aún, las fallas HTTP / 2 pueden provocar la ruptura de la compatibilidad con los métodos HTTP 1.1 y los campos de encabezado, rompiendo una funcionalidad tan simple como GET y POST .

Asegúrese de manejar correctamente la certificación SSL y la renegociación SSL Las
fallas también pueden ser mucho más complejas. Por ejemplo, la revocación y reemisión de la Certificación SSL puede ser un problema si se maneja incorrectamente. Cuando cambia el dominio de un servidor, por ejemplo, cuando una persona transfiere datos de un dominio geográfico a otro, los datos de protocolo de enlace SSL que no coinciden fallarán. Lo mismo se puede ver durante la renegociación de SSL, donde un usuario anónimo se hace identificable. Si cualquiera de estos casos se maneja incorrectamente, la falla de SSL causará una pérdida inmediata y completa de la comunicación.

Adopte estándares como UTF-8
Las fallas de soporte interno pueden incluso no ser “internas” en el sentido más estricto de la palabra. Esperar que el contenido esté estrictamente en caracteres ASCII o ISO puede causar un colapso total en la comunicación cuando se presenta con caracteres extranjeros o Unicode. Incluso algo tan simple como las discrepancias de tiempo entre las zonas horarias puede interrumpir las llamadas. La adopción de estándares como UTF-8 puede ser de gran ayuda para solucionar este problema, al igual que la desinfección de sus entradas.

Código para el peor de los casos
A veces, el problema radica en errores simples en lugar de grandes. Aunque estos errores pueden ser pequeños, su impacto puede ser enorme. No cerrar una declaración o clase es bastante fácil de pasar por alto y fundamentalmente puede romper una API.

¿Cómo se manejan estas fallas? La respuesta sucinta es "diligencia y conciencia". No codifique las API y espere que no sean manipuladas; codifíquelas para un uso funcional simple y básico en el peor de los casos. Codifique como si su cliente fuera a solicitar utilizando caracteres extranjeros, en un cambio de zona horaria de un segundo bisiesto, con una certificación vencida. Suponga que cada llamada de API realizada va a fallar, inyectando fallas en el sistema mismo, y luego desarrolle en consecuencia para solucionar esos problemas antes de enfrentarlos en la vida real.

Desarrollar bucles de enrutamiento y respaldo
Más allá de esto, es importante simplemente estar consciente de la posibilidad de fallas en el sistema. Desarrolle el enrutamiento para que el problema se aísle en un solo servidor y tenga un bucle de conmutación por recuperación para garantizar que los servidores aún manejen los datos mediante configuraciones de sistema confirmadas, precisas y efectivas.

Lea también: Supervise el estado de las API con estas 4 herramientas

Virtualiza tu API

Una de las mejores formas de garantizar que una API sea lo mejor posible es llevarla al espacio teórico. Las API son entidades vivas que respiran y, a menudo, incluso si hay fallas, pueden ser ignoradas o incluso invisibles debido a sistemas complementarios, bucles de conmutación por recuperación y otros sistemas similares. La solución es virtualizar su API y probarla en un espacio virtual. Una API virtual es una API de espacio aislado, aislada de todos los posibles soportes y sistemas de recuperación para garantizar que la API en su nivel más básico funcione según lo previsto.

Pruebe primero en una API virtualizada sin muletas
Realizar sus pruebas de API de esta manera tiene algunas ventajas muy importantes sobre las pruebas del mundo real. En primer lugar, está probando una imagen de una API, no la API en sí. Esto elimina cualquier interrupción potencial en el servicio entre su API y sus consumidores, y elimina las muletas antes mencionadas de las que la API podría depender. El otro gran beneficio de este tipo de enfoque de desarrollo es que la respuesta de la API es predecible y conocida. Cuando se desarrolla de forma aislada, la respuesta esperada no cambia por el desafío de las diferencias en servidores, procesadores, clientes y varios elementos de hardware y, por lo tanto, los errores en la respuesta, incluso los más pequeños, pueden ser dirigidos específicamente.

Acelerar los peores escenarios a la API virtual
¿Cómo entonces probamos en la API virtual? Haga una lista de los diez "peores escenarios". Incorpore desbordamiento de memoria, formación de código deficiente, certificaciones caducadas y más. Luego, pruebe las permutaciones que contiene. Haga de cada posibilidad el punto de partida de cinco posibilidades más. Pruebe los errores comunes: si una API llama al contenido de un servidor, ¿cómo reacciona ante un error 503 lanzado? ¿Qué sucede cuando los datos desencadenan un error de cliente no autorizado?

Tampoco considere sólo los errores "accidentales".
Suponga que alguien está intentando entrar en sus sistemas subyacentes y ha encontrado una debilidad en la arquitectura de la API ; luego, agréguela sin descanso con tantas variaciones como pueda. Lo que estamos haciendo aquí es esencialmente "prueba de fuego": es mejor que la API sufra todo este daño, pruebas y manipulación mientras todavía está en forma virtual que identificar estos problemas en un entorno de producción en vivo.

Probar el hardware en el que está configurada la API En
consecuencia, probar el hardware en el que está configurada la API también es de vital importancia. Debido a que estamos en el espacio virtual, implementar la API en una variedad de hardware es tan simple como cerrar la máquina virtual, cambiar los parámetros y luego abrirla nuevamente. ¿Cómo se maneja la API con diferentes configuraciones de memoria y procesamiento comunes? ¿Qué sucede durante una falla del clúster o un error de lectura del disco duro? ¿Qué hace una API cuando se reducen los subprocesos o aumentan los retrasos en la respuesta?

Un sistema virtual puede prevenir un cataclismo
Todas estas variaciones pueden tener enormes efectos en la API y los datos que maneja, y simular los cambios antes de que se implementen es increíblemente poderoso. Tenga en cuenta lo siguiente: a medida que su empresa se ocupa de un tráfico cada vez más intenso, se ha decidido que los sistemas de servidores principales deben migrarse a un nuevo clúster de servidores. A medida que se transfiere la API, las solicitudes se detienen repentinamente y el sistema deja de funcionar. Tras la inspección, se reveló que el nuevo clúster de servidores tenía limitaciones en el recuento de subprocesos reservados, y la cantidad de datos que se procesaban sobrecargaba algunos servidores con conjuntos de características de equilibrio de carga deficientes. La API no fue diseñada para manejar tales restricciones. Debido a esto, la API está inactiva durante más de cuatro horas, con un SLE (expectativa de pérdida única) de miles ... Esta falla podría haber sido aislada, documentada, y prevenido en un sistema virtual, antes de que le costara a la empresa miles de dólares. Y fue un procedimiento tan simple como crear una imagen virtual y pasar unos días probando.

Herramientas de terceros

Por supuesto, existe una amplia gama de soluciones para el seguimiento de errores que abordan estos problemas. Si bien sería casi imposible enumerar todas las soluciones y plataformas de prueba de API disponibles, hay algunos candidatos notables que serían útiles para situaciones específicas. Estos no son avales, estas soluciones son simplemente representativas de su campo y de implementaciones de soluciones efectivas.

Implementar el monitoreo de API de código abierto
Estas herramientas varían enormemente en su aplicación y metodología. Algunas soluciones, como API Fortress , han abierto las puertas para las pruebas y el monitoreo incluso para aquellos sin mucha experiencia en código utilizando interfaces gráficas. Este tipo de solución es excelente porque no solo está probando la funcionalidad de una API determinada, sino también la velocidad y precisión de la entrega de datos . Además, debido a que todas las pruebas se construyen y ejecutan internamente por desarrolladores internos, existe una relación mucho más íntima entre el desarrollador y el código que se está desarrollando.

O considere las
soluciones administradas por terceros. Por otro lado, las soluciones administradas por terceros son igualmente efectivas y pueden ser una gran opción cuando las bases de código API son grandes. Las soluciones como Runscope permiten el monitoreo activo y las alertas integradas en soluciones como PagerDuty, Slack e incluso el correo electrónico estándar básico. Si bien esta es una solución tan válida como cualquier otra, hay algo que decir sobre los peligros de transferir su monitoreo y pruebas a un proveedor externo. Al eliminarse uno mismo del proceso de identificación y reparación, es más probable que ingresen más errores y errores en la base de código; por otra parte, eliminar gran parte del peso de su equipo puede permitir un desarrollo más rápido, a costa de la integración de terceros.

Encuentre errores con procesos de prueba optimizados
Algunas soluciones son en realidad más como "portales" o "herramientas" para implementar sus propios procesos de prueba. POSTMAN es un cliente HTTP para API que permite crear y guardar consultas sencillas y claras como ajustes preestablecidos. Esto elimina gran parte de la abstracción inherente al consumo de API y genera errores claros que, de otro modo, podrían confundirse con la complejidad del código o problemas de representación. POSTMAN también permite la recopilación de puntos finales para pruebas de base grande, lo cual es significativo, especialmente cuando se reducen los errores a partes específicas de las bases de código API en funcionamiento. Esto también es importante cuando se prueban los métodos de autenticación, ya que se pueden probar y revisar varios puntos finales para garantizar respuestas seguras de los mismos.

Usar comandos cURL sin la compleja línea de comandos
HTTPie es una solución igualmente poderosa que permite a los desarrolladores usar comandos cURL sin la famosa complejidad de la utilidad de línea de comandos. Por ejemplo, una consulta simple como esta:

curl -u "NORDIC:1234" -X POST -d '{"name": "kristopher", "Age": 27, "Active": true}' -H "Content-type: application/json" https://nordic.api.com/v1029/user.json

cambió rápida y limpiamente a esto:

http -a "NORDIC:1234" POST name="kristopher" Age:=27 Active:=true https://nordic.api.com/v1029/user.json

Esto elimina gran parte de la complejidad de ejecutar comandos cURL, y cuando se extrapolan a comandos más grandes y de formato largo, las alternativas HTTPie son mucho más claras en cuanto a lo que deben hacer y cómo lo hacen.

Conclusión: pruebe con frecuencia y pruebe completamente

Ya hemos discutido anteriormente el concepto de desarrollo con una mentalidad a largo plazo , y su importancia se refleja en los enfoques que se detallan aquí. Desarrolle para las necesidades de sus consumidores ahora, teniendo en cuenta las necesidades del futuro usuario; parte de cumplir con esto es asegurarse de no introducir o ignorar los errores actuales por el bien de la funcionalidad.

Pruebe con frecuencia, pruebe completamente y pruebe teniendo en cuenta el peor de los casos: este debería ser el sello distintivo de cualquier desarrollador que se precie.

Publicar un comentario

0 Comentarios