Probador de solicitudes API
Envía solicitudes HTTP a cualquier API REST directamente desde tu navegador: define el método, los parámetros de consulta, las cabeceras, la autenticación y el cuerpo, y luego inspecciona el estado, el tiempo, las cabeceras y la respuesta JSON formateada. Copia la solicitud como código cURL o JavaScript fetch.
Última actualización:
Los parámetros de consulta se codifican y se mantienen sincronizados con la URL.
Las cabeceras personalizadas como Authorization hacen que el navegador envíe primero una solicitud previa de CORS.
Las credenciales se quedan en esta pestaña: no se guardan en el historial.
Cómo usar Probador de solicitudes API
- Elige un método e introduce la URL. Puedes omitir https://, se añade automáticamente.
- Añade parámetros de consulta y cabeceras en sus pestañas; desmarca una fila para desactivarla sin borrarla. Usa la pestaña Autenticación para un token Bearer o un inicio de sesión Basic.
- Añade un cuerpo para POST, PUT y PATCH: elige JSON, texto o datos de formulario. La cabecera Content-Type correspondiente se establece automáticamente.
- Haz clic en Enviar solicitud (o pulsa Ctrl+Intro). El estado, el tiempo, el tamaño, las cabeceras y el cuerpo formateado aparecen abajo.
- Copia la solicitud como comando cURL o código fetch() para reutilizarla en una terminal o en tu app, o elige una solicitud anterior en el Historial.
Métodos HTTP de un vistazo
| Método | Uso típico | ¿Lleva cuerpo? | Seguro / idempotente |
|---|---|---|---|
| GET | Leer un recurso o una lista | No | Seguro, idempotente |
| POST | Crear un recurso o ejecutar una acción | Sí | Ninguno de los dos |
| PUT | Reemplazar un recurso por completo | Sí | Idempotente |
| PATCH | Actualizar algunos campos de un recurso | Sí | No garantizado |
| DELETE | Eliminar un recurso | Normalmente no | Idempotente |
| HEAD | Igual que GET pero solo las cabeceras (comprobar tamaño, tipo, caché) | No | Seguro, idempotente |
| OPTIONS | Preguntar qué métodos y cabeceras permite el servidor (lo usa la solicitud previa de CORS) | No | Seguro, idempotente |
Seguro significa que la solicitud no debería cambiar datos en el servidor; idempotente significa que enviarla varias veces tiene el mismo efecto que enviarla una vez (RFC 9110).
Probar API desde un navegador: qué significa CORS para ti
Esta herramienta envía las solicitudes con el fetch() del navegador, exactamente como lo haría una aplicación web. Eso la convierte en una prueba realista de si tu API funciona para el código front-end, y también significa que se aplican las reglas de mismo origen del navegador:
- Las solicitudes simples (GET, HEAD o POST solo con cabeceras estándar y un cuerpo de formulario o texto plano) se envían directamente, pero la respuesta solo se puede leer si el servidor devuelve
Access-Control-Allow-Origincon*o el origen de esta página. - Las solicitudes con verificación previa (PUT, PATCH, DELETE, cuerpos JSON o cabeceras personalizadas como
Authorization) envían primero una solicitudOPTIONS. El servidor debe responderla conAccess-Control-Allow-MethodsyAccess-Control-Allow-Headersque cubran tu solicitud. - Las cookies solo se envían si marcas Enviar cookies, y entonces el servidor debe responder con
Access-Control-Allow-Credentials: truey un origen concreto (no*).
Si una solicitud falla aquí pero funciona con cURL, la API simplemente no permite el acceso desde navegadores en otros sitios. Es normal en muchas API privadas: usa Copiar como cURL y ejecútala en una terminal.
Preguntas frecuentes
¿Por qué recibo un error de CORS?
Los navegadores solo permiten que una página web lea la respuesta de otro sitio si ese servidor lo autoriza con una cabecera Access-Control-Allow-Origin. Muchas API públicas lo hacen; muchas API privadas o internas no. Es una regla de seguridad del navegador, no un problema de tu solicitud. Para probar esas API, copia la solicitud como cURL y ejecútala en una terminal, o habilita CORS en tu propio servidor.
¿Se envían mis datos a FreeToolCabin?
No. Las solicitudes van directamente desde tu navegador a la API que introduces. No hay servidor proxy, así que tus tokens, cuerpos de solicitud y respuestas nunca pasan por nuestros servidores. El historial se guarda solo en el almacenamiento local de tu navegador y puedes borrarlo en cualquier momento.
¿Por qué faltan algunas cabeceras de respuesta?
En las solicitudes entre orígenes, los navegadores solo exponen unas pocas cabeceras seguras (como Content-Type y Cache-Control) más las que el servidor indique en Access-Control-Expose-Headers. El resto se ocultan a las páginas web, aunque se hayan enviado.
¿Puedo establecer cualquier cabecera de solicitud?
La mayoría, pero los navegadores prohíben algunas por seguridad, como Host, Origin, Cookie, Content-Length, Referer y Connection. El navegador las establece por sí mismo. Las cabeceras personalizadas como Authorization o X-Api-Key funcionan, pero provocan una solicitud previa de CORS (OPTIONS) que el servidor debe aceptar.
¿Puedo llamar a una API http://?
Si esta página está abierta por HTTPS, los navegadores bloquean las solicitudes http:// simples como contenido mixto, excepto a localhost. Usa la dirección https:// de la API o ejecuta la solicitud con cURL.
¿Qué significan los tiempos?
El tiempo hasta las cabeceras se mide desde que se envía la solicitud hasta que llegan la línea de estado y las cabeceras (incluye DNS, conexión, TLS y tiempo del servidor). El tiempo total incluye además la descarga del cuerpo completo.
¿Cuál es la diferencia entre PUT y PATCH?
PUT reemplaza el recurso completo con el cuerpo que envías, mientras que PATCH aplica una actualización parcial solo a los campos que incluyes. POST normalmente crea un recurso nuevo y DELETE elimina uno.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.