Añadir ralentizaciones y códigos de error - Curso de construcción de una API de ejemplo en C#

Introducción a la API de muestra y su propósito

Tim comienza la lección reiterando el valor de contar con una API de ejemplo cuando se aprende desarrollo web. Una API de este tipo ofrece algo concreto con lo que probar las aplicaciones frontales.

Al final del curso, Tim pretende construir una API robusta que incluya:

• Datos de muestra

• Documentación

• Comprobaciones

• Ralentizaciones simuladas

• Errores simulados

• Opciones de despliegue mediante Docker y VPS

En esta lección específica, Tim se centra en la simulación de ralentizaciones y en la generación de códigos de error para obtener un comportamiento realista de la API en condiciones adversas.

Añadir retrasos artificiales a los puntos finales de la API

Tim empieza añadiendo un parámetro opcional de retraso a determinados puntos finales de la API, en particular los que tratan de datos de cursos. Su objetivo es simular respuestas API lentas para mejorar las pruebas frontales.

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

Prueba del mecanismo de retardo

Tim realiza algunas pruebas con Postman (o un clon de Postman) para verificar la lógica del retardo. Por ejemplo:

• Un delay=5000 (5 segundos) hace que la API haga una pausa antes de devolver los resultados.

• Un delay=500 da como resultado una pausa más corta.

Observa que el retraso real siempre será ligeramente superior al valor especificado debido a la sobrecarga de procesamiento, un matiz importante en el mundo real. Como señala Tim en 5:09, no se trata de cronometrar la API al milisegundo, sino de simular un umbral.

Ampliación de la funcionalidad de retardo a más puntos finales

Tim no se limita al punto final "cargar todos los cursos". Quiere coherencia, así que implementa la misma capacidad de retardo en el punto final "cargar curso por ID".

En el minuto 6:15, se encuentra con un problema: un conflicto de nomenclatura debido a la adición automática de "Async" al nombre del método al convertirlo en asíncrono. Tim ajusta los nombres de ambos métodos para alinearlos con la convención de nomenclatura Async en aras de la claridad y la coherencia.

Las pruebas confirman la implementación:

• Se respetan los plazos.

• Los registros inexistentes devuelven 404 como se esperaba tras el retraso.

• Tim señala que se trata de una peculiaridad de la interfaz de usuario de Postman y no de un problema con la API en sí (8:00).

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Prueba del punto final de error

Tim prueba ahora el punto final de error pasando varios códigos de estado:

• 400 devuelve "Solicitud incorrecta"

• 401 devuelve "No autorizado"

• 404 devuelve "No encontrado"

• 301 devuelve "Movido permanentemente"

• 405 devuelve "Método no permitido"

Esto demuestra la flexibilidad del punto final, no solo para los códigos de error, sino para cualquier código de estado HTTP. A las 13:04, Tim confirma que este enfoque es ideal para probar cómo las aplicaciones frontales gestionan las diferentes respuestas del servidor.

Aunque pensó en llamarlo /httpcode, se quedó con /error por simplicidad, ya que se utiliza principalmente para simular condiciones de error.

Resumen de las mejoras funcionales

Tim concluye el vídeo resumiendo las mejoras introducidas en la API:

• Slowdowns simulan la latencia real en las respuestas de la API.

• Simulación de errores proporciona flexibilidad para realizar pruebas con prácticamente cualquier respuesta HTTP.

• Estas características hacen que la API de muestra sea más robusta y valiosa para escenarios de pruebas realistas.

A las 14:16, Tim subraya la importancia de estas herramientas para probar cómo se comporta tu app bajo diferentes estados de la API, como respuestas retrasadas o diversos errores del servidor.

Lo que viene a continuación: Dockerizar la API

Aunque no se trata en detalle en este vídeo, Tim insinúa el siguiente paso: Dockerizar la API. Esto permite a los desarrolladores ejecutar la API de muestra localmente en un contenedor Docker autónomo, lo que facilita su despliegue y uso compartido en distintos entornos.

Reflexiones finales

Tim concluye el vídeo reiterando su compromiso de crear una API de muestra completa que incluya funciones realistas que los desarrolladores necesiten probar. Entre ellas se incluyen:

• Retrasos

• Errores

• Comprobaciones

• Planes futuros para la autenticación y los puntos finales avanzados

El objetivo es sencillo pero poderoso: dotar a los desarrolladores de una herramienta que imite las peculiaridades de las API reales, para que sus aplicaciones sean sólidas, fiables y fáciles de usar.

Conclusión

Al final de esta lección, los espectadores estarán equipados con una mejor comprensión de cómo y por qué introducir retrasos artificiales y respuestas de error en sus API. El enfoque de Tim Corey es metódico, práctico y está directamente vinculado a las necesidades de las pruebas de aplicaciones del mundo real. Si quieres mejorar tu juego de pruebas de API, esta lección es un excelente recurso a seguir, y ahora sabes exactamente dónde buscar.

Vea la lección completa vídeo de Tim Corey para obtener orientación práctica.