Gestión de errores y pruebas de API REST

Name: Gestión de errores y pruebas de API REST
Author: Josh Guardino

Aprenda a lidiar con los errores de las APIsREST y a crear y ejecutar pruebas automatizadas

Preview the first lesson free — get full access to all 3 lessons.

Curso: bajo demanda

Hola, mi nombre es Josh Gardino, y en estas lecciones, te mostraré cómo manejar los errores y probar las API REST. Recuerde que los códigos de estado de respuesta HTTP se dividen en varios grupos. Los códigos de estado en el rango 400 y 500 se consideran errores. Sin embargo, la diferencia crítica es que los códigos de estado que comienzan con un cuatro son errores del cliente y los códigos de estado que comienzan con cinco son errores del servidor. Los errores del cliente serían errores relacionados con la solicitud en sí. La solicitud podría haber contenido JSON con formato incorrecto, el acceso a la ruta solicitada estaba prohibido, no se pudo encontrar el recurso solicitado, y más. Cuando se producen errores del cliente, es importante que el servidor responda con el código de estado de la serie 400 correcto. Sin embargo, mantener todos los detalles sobre el error del cliente normalmente no se requiere en el lado del servidor. El cliente debe ser capaz de abordar el problema. y enviar una nueva solicitud. De mayor preocupación en el lado del servidor son los códigos de error del servidor, y estos son los que comienzan con cinco. Aunque existen numerosos códigos de respuesta de error del servidor, con mucho, el más importante y relevante es 500. 500 indica error interno del servidor por una condición inesperada en el lado del servidor, lo que significa que ocurrió un error. El código de estado 500 está destinado ser una respuesta genérica comodín. Sin embargo, suele ser el único tipo del código de error del lado del servidor que el código del lado del servidor de la API REST necesita manejar. Se pueden encontrar otros códigos de error del lado del servidor por un cliente, como 503 indicando que el servidor no está listo. Pero este tipo de respuestas normalmente se envían por una puerta de enlace API y no por la propia aplicación. Vamos a ver en el Departamento de Vehículos Motorizados API en Postman. Aquí está el punto final GET v1/drivers y cuando hago clic en Enviar, se devuelve un código de estado 200 y una lista de todos los controladores de la base de datos. Ahora veamos cómo se ve esto en el código fuente. Aquí está el controlador para el método GET. Realiza una consulta de selección en la base de datos y devuelve todos los datos. Esto funciona bien si no se encuentran errores. Sin embargo, hagamos que ocurra un error. En la línea 12, voy a ingresar un código no válido. Reiniciemos el servidor y volvamos a Postman. Haré clic en enviar y, como puede ver, No recibí un código de estado ni ningún tipo de respuesta. El cartero muestra un error ECONNRESET. Esto significa que el servidor no respondió. con cualquier cosa que Postman pudiera procesar. Volvamos a donde se está ejecutando el servidor. Mi servidor local detectó con precisión el error xyz y mostró los detalles completos en la ventana de la consola. Estos detalles se denominan seguimiento de pila. y son muy importantes para fines de depuración. La primera línea en la salida de error me dice que esto fue un error de referencia porque el servidor no entendió qué es xyz, por lo que el error se está capturando correctamente pero el cliente no tiene idea de lo que pasó. El servidor podría estar caído, podría haber un problema de red en el lado del cliente, podría haber un error del lado del servidor pero el cliente no tiene forma de saber lo que sucedió y eso se debe a que este código no realiza ningún tipo de manejo de errores. Cuando se produce el error, el servidor detecta que algo salió mal pero no se envía ninguna respuesta porque para el método GET, el único tipo de respuesta que se envía es un 200. Ahora, agreguemos un poco de manejo de errores a la aplicación Node.js Express con sentencias try y catch. Ahora el error está siendo manejado. y todos los errores se detectarán en la línea 16. En la línea 17, envío un estado de 500 al cliente. Volvamos a Postman y probemos esto. Ahora, cuando envío la solicitud, Recibo una respuesta y tiene un código de estado 500 indicando un error interno del servidor. El cliente no sabe exactamente lo que pasó. en el lado del servidor, pero tiene mucha más información que con la solicitud anterior. Ciertamente es posible enviar los detalles completos del error de vuelta al cliente, junto con el código de estado de error del servidor interno 500 pero esto es ciertamente problemático. Lo más importante, esto expone detalles internos sobre la API y esto presenta un problema de seguridad potencialmente grave pero además, esta información no es de ayuda para el cliente, así que no hay razón para enviarlo pero eso no significa que el servidor tiene que devolver un mensaje de respuesta del servidor genérico. Volvamos al código y agregue un mensaje de error amistoso. Ahora, cuando enviamos esta solicitud, todavía recibimos un 500 pero con un mensaje de error personalizado. Otra razón para usar un mensaje de código de estado 500 personalizado es proporcionar al cliente un seguimiento o ID de correlación que el personal del lado del cliente de la API podría compartir con el personal del lado del servidor para realizar una solución de problemas detallada. Gracias por ver. Estén atentos a la próxima lección donde les mostraré cómo usar pruebas automatizadas para solicitudes GET en API REST.

Principiante Proveedor : Josh Guardino 3 lecciones · 17m en Árabe, Alemán, Inglés, Español, Francés, Portugués, Chinese

Descripción del curso

Las APIs son, por su naturaleza, aplicaciones de software distribuidas que consisten en clientes y servidores remotos que se conectan a través de una red. Si bien la comunicación remota ha cambiado el mundo tal como lo conocemos, también trae una enorme lista de posibles peligros y problemas. Los servidores y las redes se caen. Las computadoras pueden actuar de maneras inesperadas. Los clientes cambian y no pueden procesar solicitudes y respuestas. Todo esto se suma a una verdad constante: el único factor conocido es lo desconocido.

Para gestionar lo inesperado, es importante que los clientes y servidores RESTful se ocupen de estas condiciones correctamente. En estas lecciones aprenderá cómo se producen los errores de ambos lados y cómo se puede procesar de manera óptima la combinación de detalles de error, códigos de estado y mensajes.

La mejor defensa contra la inestabilidad y la inconsistencia con el software es probarlo de manera constante y periódica. Le enseñaremos a usar TestProject, una herramienta gratuita basada en la web, para crear scripts y automatizar pruebas de APIs REST para descubrir e identificar condiciones de error y proporcionar información útil para ladepuración y el ajuste del desempeño.

Lo que aprenderás

Identificar los tipos más comunes de errores de API REST y sus códigos de estado correspondientes
Reconocer cómo ocurren errores tanto en el lado del cliente como del servidor de una API
Procesar detalles de errores, códigos de estado y mensajes de manera óptima para manejar lo inesperado correctamente
Configurar y ejecutar TestProject para escribir y automatizar pruebas de API REST para solicitudes GET
Configurar y ejecutar TestProject para solicitudes POST, PUT, PATCH y otras solicitudes de escritura
Utilizar pruebas automatizadas de API REST para descubrir condiciones de error e información de soporte para depuración y ajuste de rendimiento

Puntos clave

Las APIs son aplicaciones distribuidas de clientes remotos y servidores que se conectan a través de una red, lo que introduce muchos riesgos potenciales como servidores y redes que se desconectan o clientes que no pueden procesar solicitudes y respuestas.
Los clientes y servidores RESTful deben tratar condiciones inesperadas de manera correcta combinando detalles de errores, códigos de estado y mensajes, y procesándolos de manera óptima.
Las pruebas consistentes y regulares son la mejor defensa contra la inestabilidad e inconsistencia del software.
TestProject es una herramienta gratuita basada en web utilizada para escribir y automatizar pruebas de API REST con el fin de identificar condiciones de error y respaldar la depuración y el ajuste de rendimiento.
El curso cubre el manejo de solicitudes GET y solicitudes de escritura como POST, PUT y PATCH.

Preguntas frecuentes

¿Qué cubre este curso?

Cubre cómo ocurren errores tanto en el lado del cliente como del servidor de las API REST, cómo se pueden procesar de manera óptima los detalles de errores, códigos de estado y mensajes, y cómo usar TestProject para escribir y automatizar pruebas de API REST para descubrir condiciones de error y respaldar la depuración y el ajuste de rendimiento.

¿Qué herramienta de prueba se utiliza en este curso?

El curso utiliza TestProject, una herramienta gratuita basada en web, para escribir y automatizar pruebas de API REST.

¿Qué tipos de solicitudes de API enseña el curso a probar?

Enseña a configurar y ejecutar TestProject para solicitudes GET así como para solicitudes POST, PUT, PATCH y otras solicitudes de escritura.

¿Qué habilidades ayuda a desarrollar este curso?

Aborda habilidades que incluyen Diseño de API, Gestión de API, Pruebas de API, Desarrollo de API REST, Cliente REST y API RESTful.

¿Qué lecciones se incluyen en este curso?

El curso incluye tres lecciones: Manejo y Pruebas de Errores de API REST; Métodos HTTP GET; y Solicitudes POST, PUT y PATCH.