Constructor de Solicitudes API
¿Por qué usar un Constructor de Solicitudes API?
Probar las API REST normalmente requiere instalar Postman, Insomnia o escribir comandos curl. Nuestro Constructor de Solicitudes API basado en el navegador requiere cero instalación: simplemente ábralo y comience a enviar solicitudes. Admite todos los métodos HTTP, encabezados personalizados, cuerpos JSON y parámetros de consulta, lo que lo hace perfecto para pruebas rápidas de API, exploración de API públicas y depuración de integraciones.
Todos los Métodos HTTP
Admite GET, POST, PUT, PATCH, DELETE con encabezados personalizados y cuerpo JSON/formulario
Respuesta Formateada
El cuerpo de la respuesta se imprime de forma atractiva de manera automática, con código de estado, texto de estado HTTP y tiempo de respuesta
Cero Configuración
No requiere instalación: funciona completamente en su navegador sin necesidad de cuentas ni complementos
Cómo enviar una Solicitud API
Introducir URL y Método
Escriba la URL del endpoint de la API y seleccione el método HTTP (GET, POST, etc.)
Añadir Encabezados y Cuerpo
Cambie a la pestaña Encabezados para añadir Authorization, Content-Type y otros encabezados. Use Cuerpo para datos POST/PUT.
Enviar e Inspeccionar
Haga clic en Enviar para realizar la solicitud. El cuerpo de la respuesta, el código de estado y el tiempo aparecen a continuación.
Casos de Uso del Constructor de Solicitudes API
Depuración de API
Pruebe endpoints de API individuales con encabezados y cuerpo personalizados para depurar problemas de autenticación y datos
Prueba de Tokens de Autenticación
Pruebe los esquemas de autenticación token Bearer, Basic Auth y clave de API sin escribir código
Exploración de API
Explore API públicas (GitHub, OpenWeather, JSONPlaceholder) y entienda sus respuestas
Reproducción de Errores
Reproduzca y documente errores de API con detalles exactos de solicitud/respuesta para presentar informes de errores
Mejores Prácticas para Pruebas de API
✓ Establecer siempre Content-Type
Al enviar un cuerpo JSON, incluya siempre Content-Type: application/json. Sin él, muchas API rechazarán o malinterpretarán su solicitud.
✓ Entender las Limitaciones de CORS
Los navegadores bloquean las solicitudes de origen cruzado sin los encabezados CORS adecuados. Si una solicitud falla en el navegador, intente con curl o un proxy del lado del servidor en su lugar.
✓ Nunca codificar las claves de API
Use variables de entorno en el código de producción. El constructor de solicitudes es solo para pruebas; no comparta capturas de pantalla que contengan claves de API activas.
✓ Comprobar Códigos de Estado HTTP
200=OK, 201=Creado, 400=Solicitud Incorrecta, 401=No Autorizado, 403=Prohibido, 404=No Encontrado, 500=Error del Servidor. Siempre verifique primero el código de estado.
❓ Preguntas Frecuentes
¿Por qué falla mi solicitud de origen cruzado?
Los navegadores imponen restricciones CORS (Intercambio de Recursos de Origen Cruzado). Si la API de destino no incluye los encabezados Access-Control-Allow-Origin, el navegador bloquea la solicitud. Esto no es un error: use curl o un proxy de backend para las API sin soporte CORS.
¿Puedo enviar solicitudes multipart/form-data?
El constructor actual admite cuerpos JSON y de texto sin formato. Para datos de formulario multiparte (cargas de archivos), use el envío de formulario nativo del navegador o una herramienta dedicada como Postman.
¿Es este un reemplazo de Postman?
Para pruebas rápidas y exploración, sí. Para la colaboración en equipo, colecciones guardadas, entornos y pruebas automatizadas, Postman o Bruno ofrecen más funciones. Esta herramienta sobresale en las pruebas de API instantáneas sin configuración.
¿Cuál es la diferencia entre PUT y PATCH?
PUT reemplaza todo el recurso con el cuerpo de la solicitud. PATCH aplica una actualización parcial: solo se cambian los campos incluidos en el cuerpo. La mayoría de las API REST usan PATCH para actualizaciones a fin de evitar sobrescribir campos no modificados.