Cliente HTTP

Casos de uso

• Probar un endpoint de tu API mientras lo desarrollas, sin salir del navegador ni instalar un cliente.
• Comprobar que una clave de API funciona antes de meterla en el código.
• Ver qué devuelve exactamente una API pública antes de escribir el código que la consume.
• Repetir una petición que has visto en las herramientas de desarrollo: copiar como cURL, pegarla aquí y trastear con ella.
• Convertir un curl de la documentación de una API en código fetch de JavaScript o en PowerShell.
• Entender un error de tu aplicación: ver si el 401 es por el token, por la cabecera o por la ruta.
• Averiguar por qué una llamada falla en el navegador y funciona en el servidor, que casi siempre es CORS o una cabecera prohibida.
• Mirar las cabeceras de caché de una URL para saber por qué se sirve vieja.
• Comprobar si una API respeta los límites de peticiones, mirando las cabeceras de cuota.
• Enseñar cómo funciona HTTP viendo métodos, códigos y cabeceras de verdad en lugar de un diagrama.

Cómo se usa

1. Elige el método y escribe la dirección. Si nunca has usado esto, abre «Ejemplos» y carga uno de los que ya vienen preparados.
2. Añade parámetros y cabeceras en sus tablas. Si la dirección ya lleva una consulta, hay un botón para pasarla a la tabla.
3. Si la petición lleva datos, ve a «Cuerpo» y elige JSON, texto plano o formulario. El JSON se comprueba mientras escribes.
4. En «Auth» pon el token, el usuario y contraseña o la clave de API; la cabecera se construye sola.
5. Pulsa Enviar, o Ctrl+Enter. Mientras va, el mismo botón cancela.
6. Mira el resultado: el código y su explicación, el tiempo, el tamaño, las cabeceras comentadas y el cuerpo formateado.
7. Si la bloquea CORS, copia el comando de curl que aparece en el diagnóstico y lánzala desde tu terminal.

Qué incluye Cliente HTTP

• Los siete métodos: GET, POST, PUT, PATCH, DELETE, HEAD y OPTIONS.
• Tablas de parámetros y de cabeceras, con casilla para desactivar una fila sin borrarla.
• Cuerpo en JSON con comprobación de sintaxis y botón de formatear, en texto plano o como formulario.
• Autenticación Bearer, Basic (que construye el base64) o clave de API en la cabecera que tú digas.
• Aviso de las cabeceras que el navegador no deja poner (Host, Origin, Cookie, Content-Length…) antes de enviar, no después.
• Aviso de cuándo la petición obliga al navegador a pedir permiso antes con OPTIONS, que es la causa más común de que algo funcione en curl y no en el navegador.
• Control del tiempo de espera, de las redirecciones, de las cookies y de la caché.
• Cancelar una petición en vuelo.
• Código de respuesta explicado en castellano, incluida la diferencia entre 401 y 403 o entre 301 y 307.
• Cabeceras de la respuesta con una nota de para qué sirve cada una, y aviso de cuándo el navegador está escondiendo las demás.
• Cuerpo formateado con resaltado, vista en crudo, copia, descarga y vista previa si es una imagen.
• Tiempo de respuesta, tamaño del cuerpo y bytes transferidos cuando el servidor deja verlos.
• Importación de comandos curl, incluido el «Copiar como cURL» de las herramientas de desarrollo del navegador.
• Exportación a curl, a fetch de JavaScript y a PowerShell, con la petición tal y como está montada.
• Diagnóstico de los fallos: distingue CORS, contenido mixto, tiempo agotado y problema de red, y dice qué hacer en cada caso.
• Historial de la sesión para volver a cargar cualquier petición anterior, solo en memoria.

Preguntas frecuentes

¿Por qué me da error una petición que en curl funciona?

Casi siempre por CORS. Un programa de terminal abre la conexión y lee lo que venga; un navegador, no: solo te deja leer la respuesta de otro dominio si ese dominio lo autoriza con la cabecera Access-Control-Allow-Origin. Cuando falta, la petición puede haber llegado al servidor y haberse ejecutado, pero el navegador tira la respuesta antes de que la veas. No es un fallo de esta herramienta ni del servidor: es la regla que impide que cualquier web que abras lea, desde tu sesión, el correo o el banco que tienes abiertos en otra pestaña.

¿Y no podéis saltaros CORS con un proxy, como otras webs?

Podríamos, y por eso mismo no lo hacemos. Un proxy significa que tus peticiones —con sus tokens, sus claves y sus respuestas— pasan por un servidor nuestro, que podría guardarlas. Este sitio entero está hecho sobre la promesa de que no hay servidor: si la herramienta necesitara uno, no entraría aquí. Cuando CORS bloquee algo, tienes el comando de curl a un clic, y esa es la vía correcta para una prueba con credenciales de verdad.

Entonces, ¿qué APIs funcionan aquí?

Todas las que declaren CORS abierto, que son muchísimas: GitHub, la mayoría de APIs públicas de datos, casi todo lo pensado para consumirse desde el navegador. También la tuya, si estás desarrollando y le has puesto los permisos, que es el caso de uso principal. Y todas, sin excepción, se pueden preparar aquí y lanzar desde la terminal con el comando exportado.

¿Puedo probar una API en mi propio ordenador, en localhost?

Sí, y es lo más útil de todo. Los navegadores tratan localhost como origen de confianza, así que http://localhost:3000 funciona aunque esta página vaya por HTTPS. Lo que sí necesitas es que tu servidor local mande las cabeceras de CORS autorizando este origen; en la mayoría de frameworks es una línea. Si prefieres no tocar nada, exporta a curl.

¿Se guardan mis tokens en alguna parte?

No. Nada de lo que escribas se guarda: ni en un servidor, que no lo hay, ni en el almacenamiento del navegador. El historial que ves abajo vive en la memoria de la pestaña y desaparece al recargar. Aun así, la recomendación honesta es la de siempre: para credenciales de producción, la terminal de tu equipo es mejor sitio que una pestaña del navegador con extensiones instaladas.

He puesto una cabecera y no llega. ¿Por qué?

Porque hay una lista de cabeceras que solo controla el navegador y que ignora si las escribes: Host, Origin, Referer, Cookie, Content-Length, Connection y unas cuantas más, además de todas las que empiezan por Sec- o Proxy-. Es para que una página no pueda mentir sobre quién es o falsear una petición. Aquí se avisa en cuanto escribes una de ellas, en lugar de dejarte pensar que ha viajado.

¿Qué es eso del preflight que me avisa a veces?

Que tu petición no es de las «simples», y entonces el navegador manda antes un OPTIONS al servidor preguntando si le deja hacerla. Ocurre si el método no es GET, HEAD o POST, si llevas cabeceras fuera de una lista muy corta (Authorization, por ejemplo) o si el Content-Type no es texto plano ni formulario. Si el servidor no contesta ese OPTIONS autorizando, la petición de verdad no llega a salir. Es el motivo más común de que un POST con JSON y token funcione en curl y no en el navegador.

La respuesta trae menos cabeceras de las que debería.

Es otra regla del navegador. De una respuesta de otro dominio solo se pueden leer siete cabeceras: Content-Type, Content-Length, Cache-Control, Expires, Last-Modified, Content-Language y Pragma. El resto —tu X-Request-Id, las de cuota, el ETag— existen y llegan, pero el navegador no las expone salvo que el servidor las autorice con Access-Control-Expose-Headers. Cuando pasa, aquí se avisa para que no lo tomes por un fallo. Con curl se ven todas.

¿Puedo subir un archivo?

No. Subir archivos se hace con multipart/form-data, y montar eso a mano en un cliente así aporta poco: lo normal es probar la subida desde el código o desde curl con -F. El cuerpo aquí puede ser JSON, texto plano o un formulario de los de toda la vida (application/x-www-form-urlencoded), que cubre la inmensa mayoría de las pruebas.

¿Sirve para hacer pruebas de carga o lanzar muchas peticiones?

No, y a propósito. Esto manda una petición cada vez, la que tú pulses. Para medir rendimiento están las herramientas hechas para eso, que corren en un servidor y controlan la concurrencia. Y lanzar peticiones masivas contra un servicio ajeno sin permiso no es una prueba de carga: es un ataque.

¿Qué diferencia hay entre esto y Postman o Insomnia?

Que aquellos son programas de escritorio: abren la conexión ellos mismos, así que no tienen CORS ni cabeceras prohibidas, y guardan colecciones, entornos y variables. Esto es una página: se abre en un segundo, no pide instalar ni registrarse y no manda nada a ninguna parte, a cambio de jugar con las reglas del navegador. Para trastear con una API pública, mirar qué devuelve un endpoint o convertir un curl en código, esto sobra; para un trabajo diario con colecciones y entornos, el programa de escritorio es la herramienta.

¿Por qué me sale «contenido mixto»?

Porque esta página se sirve por HTTPS y estás pidiendo una dirección http:// sin cifrar. El navegador lo corta antes de que salga, para que nadie pueda leer o modificar por el camino lo que va dentro de una página segura. La excepción es localhost, que se considera de confianza. Si el servidor de destino solo habla HTTP y no es local, esa petición hay que hacerla desde la terminal.

Privacidad

Esta herramienta sí sale a internet, y es la única manera de que sirva para algo: manda la petición que tú escribes al servidor que tú indicas. Conviene tener claro cómo.

La petición sale directamente de tu navegador al destino. No pasa por ningún servidor nuestro, ni por un proxy, ni queda registrada en ninguna parte: este sitio no tiene backend. Quien recibe la petición es el servidor al que apuntas, y nadie más por el camino, aparte de los intermediarios normales de cualquier conexión de internet.

Eso incluye tus credenciales: el token o la contraseña que escribas viajan al destino y a nadie más, y no se guardan aquí. Ni en un servidor, ni en el almacenamiento del navegador. El historial de esta sesión vive en la memoria de la pestaña y se borra al recargar.

Es la diferencia con los clientes HTTP web que funcionan con cualquier API: para saltarse las restricciones del navegador tienen que reenviar tus peticiones desde su propio servidor, y ahí tus URLs y tus claves pasan por una máquina que no es la tuya. Aquí no ocurre, y el precio es que las APIs que no autorizan CORS no se pueden probar desde esta página. Para esas está el comando de curl que la herramienta te da hecho.

Las peticiones se mandan con referrerPolicy «no-referrer»: el destino no recibe de qué página se le llama.

Los ejemplos de la lista apuntan a servicios de terceros (GitHub, JSONPlaceholder, httpbin). Si los usas, tu navegador les habla directamente a ellos, con lo que eso implica: verán tu dirección IP, como cualquier web que visitas.