Cómo probar una API REST con Postman
Comprende la solicitud de la API REST
Antes de abrir Postman, identifica qué espera la API y qué debería devolver. Una solicitud suele contener un método HTTP, una URL, encabezados, parámetros de consulta y, en ocasiones, un cuerpo de solicitud. Por ejemplo, una API de productos podría usar GET https://api.example.com/products/42 para recuperar el producto 42, mientras que POST https://api.example.com/products crea un producto nuevo.
Comienza con la documentación de la API y anota el método, el endpoint, el método de autenticación y el formato de datos necesarios. Comprueba si el servicio espera JSON, datos de formulario o parámetros de consulta como category=books. Esta preparación evita un error común de los principiantes: cambiar varios ajustes a la vez sin saber qué parte provocó el fallo.
Crea un espacio de trabajo y un entorno en Postman
Crea un espacio de trabajo de Postman para el proyecto y agrupa las solicitudes en carpetas como Users, Products y Orders. Mantener juntas las solicitudes relacionadas facilita repetir un flujo de trabajo y comparar resultados. Un proyecto pequeño puede necesitar solo diez solicitudes, pero una organización clara se vuelve valiosa cuando la colección crece hasta incluir docenas de endpoints.
Usa variables de entorno para los valores que cambian entre desarrollo, staging y producción. En lugar de escribir la dirección completa del servidor en cada solicitud, guárdala como una variable de URL base y haz referencia a ella de forma coherente. El mismo enfoque funciona para un token de acceso, un ID de usuario o una versión de la API, al tiempo que reduce las solicitudes accidentales al servidor equivocado y evita ediciones repetidas.
Envía primero una solicitud GET
Una solicitud GET es una primera comprobación útil porque normalmente lee datos sin modificar el servidor. Introduce el endpoint, selecciona GET, añade la autorización necesaria y envía la solicitud. Si el endpoint es https://api.example.com/users/15, verifica que la respuesta represente al usuario 15, en lugar de limitarte a confirmar que el servidor devolvió algo.
Después de enviar la solicitud, inspecciona el código de estado, el tiempo de respuesta, las cabeceras y el cuerpo. Un estado 200 suele indicar que la operación se realizó correctamente, pero también debes confirmar que campos como id, email o createdAt tengan los tipos y valores esperados. Si la respuesta es un array vacío, compara los parámetros de consulta y los datos de prueba antes de decidir que la API está dañada.
Prueba POST, PUT y DELETE de forma segura
Escribe solicitudes que modifiquen datos solo después de que la operación de lectura funcione. Para una solicitud POST, elige el formato de cuerpo correcto, normalmente JSON sin procesar, y envía una carga útil válida y pequeña, como el nombre, el precio y la cantidad en stock de un producto. Confirma que el servidor devuelva una respuesta de creación adecuada, como el estado 201, y comprueba que el registro devuelto tenga un identificador generado.
Prueba los datos no válidos y los casos límite con la misma intención que los datos válidos. Prueba con un nombre obligatorio ausente, un precio negativo, una descripción extremadamente larga o una fecha no válida; después, comprueba si la API devuelve una respuesta 4xx clara en lugar de crear datos corruptos. Para las solicitudes PUT, PATCH y DELETE, utiliza siempre que sea posible un registro de prueba específico, de modo que los experimentos no modifiquen ni eliminen información real de clientes.
Comprueba los códigos de estado, las cabeceras y JSON
No evalúes una solicitud basándote únicamente en el código de estado. Inspecciona las cabeceras de respuesta para comprobar el tipo de contenido, el comportamiento de la caché, los identificadores de solicitud y la información sobre los límites de solicitudes; después, confirma que el cuerpo sea un JSON válido cuando se espere JSON. Una respuesta con estado 200 pero con una página de error HTML, un campo ausente o un tipo de contenido incorrecto sigue representando una prueba fallida para el cliente que consume la API.
Utiliza comprobaciones realistas para los resultados HTTP habituales. Un inicio de sesión válido puede devolver 200, un recurso recién creado puede devolver 201, una solicitud no válida puede devolver 400, la falta de credenciales puede devolver 401 y un usuario autenticado sin permisos puede recibir 403. Distinguir estos casos ayuda a los desarrolladores a solucionar el problema real en lugar de cambiar repetidamente el cuerpo de la solicitud.
Añade pruebas de Postman para realizar comprobaciones repetibles
La inspección manual resulta útil durante la exploración, pero las pruebas automatizadas agilizan las verificaciones repetidas. En Postman, añade pruebas que confirmen el código de estado, el umbral de tiempo de respuesta, el tipo de contenido y la presencia de campos importantes. Por ejemplo, un endpoint de usuario puede verificar que la respuesta sea 200 y que el objeto devuelto contenga un id y un valor de email.
Mantén las aserciones lo bastante específicas para detectar regresiones sin hacerlas frágiles. Comprobar que existe un id suele ser más duradero que esperar un valor numérico permanente, mientras que verificar que un email coincide con un formato válido puede detectar respuestas malformadas. Ejecuta la misma colección después de un cambio en el código e investiga el primer fallo antes de asumir que todos los fallos posteriores tienen una causa independiente.
Termina con una lista de comprobación práctica para la depuración
Cuando una solicitud falla, compara el método, la URL, los parámetros de consulta, los encabezados, la autenticación y el cuerpo con la documentación, elemento por elemento. Busca pequeñas diferencias, como una barra faltante, un token caducado, un encabezado llamado Content-Type con un valor incorrecto o una sintaxis JSON que utiliza una coma final. Reproduce la solicitud con el payload más pequeño posible para que sea más fácil aislar el origen del error.
Antes de compartir una colección, elimina de los ejemplos y las variables guardadas las contraseñas reales, los datos personales y los tokens de producción. Registra el código de estado esperado y una respuesta representativa para cada solicitud importante y, después, ejecuta la colección en un entorno de pruebas seguro. Esta revisión final convierte Postman de una herramienta para hacer clic manualmente en Send en una lista de comprobación repetible para validar el flujo de trabajo completo de una REST API.
Artículos relacionados
Lecturas adicionales
Etiquetas :
- Desarrollo web
