Cliente / probador de API REST

Componga y envíe peticiones HTTP con parámetros de consulta, cabeceras, cuerpos JSON o de formulario, y autenticación Basic o Bearer; después inspeccione el estado, los tiempos y las respuestas JSON con formato. Importe un comando cURL existente o copie la petición actual de vuelta como cURL. ¿Prefiere crear peticiones reutilizables paso a paso? Use el Constructor de peticiones HTTP. Vea también la familia de herramientas de API.
Todo se ejecuta localmente en su navegador. Las peticiones de origen cruzado están sujetas a la política CORS del servidor de destino; si una petición falla, consulte la nota de abajo.
Pegue un comando cURL
Parámetros de consulta
Cabeceras
Cuerpo
Autorización
Opciones
Cuando se rellena, la URL de la petición se añade a este prefijo. Útil para servidores bloqueados por CORS.
200
Cuerpo Cabeceras

                                                                

                                                                

                                                                    

                                                                

                                                            


                                                            

                                                            
Por qué puede fallar una petición: los navegadores bloquean las lecturas de origen cruzado salvo que la API devuelva Access-Control-Allow-Origin. Si el destino no permite CORS, puede ejecutar un proxy CORS propio y pegar su URL en el prefijo de proxy de arriba, o usar el Conversor de cURL para ejecutar la petición desde una terminal. Los cuerpos de las peticiones GET y HEAD se ignoran, y una herramienta WebSocket está aparte, en el Probador de WebSocket.


                                                            

                                                                Métodos HTTP explicados
                                                                
El método que elija indica al servidor qué quiere hacer con la URL. Esto es lo que significa cada uno de los siete verbos que puede enviar esta herramienta:

                                                                
GET — Obtiene un recurso: una página web, una imagen, una lista de registros. «Dame lo que hay en esta URL». Es de solo lectura y seguro de repetir, y normalmente no lleva cuerpo de petición (si un GET tiene cuerpo, se ignora).

                                                                
POST — Envía datos nuevos al servidor, normalmente para crear un recurso o disparar una acción: enviar un formulario, subir un archivo, iniciar un trabajo. La carga viaja en el cuerpo de la petición. POST no es idempotente: enviar dos veces el mismo POST puede crear dos registros.

                                                                
PUT — Sustituye todo el recurso de la URL por lo que envía. El cuerpo debe contener la versión nueva completa del recurso. PUT es idempotente: repetir la misma petición produce el mismo efecto que enviarla una sola vez.

                                                                
PATCH — Cambia solo una parte de un recurso. Envía solo los campos que quiere actualizar, p. ej. {"email": "new@example.com"}, en lugar de todo el registro. Elija PATCH cuando un PUT completo le obligaría a reenviar campos que no está tocando.

                                                                
DELETE — Elimina el recurso de la URL. DELETE es idempotente: borrar algo que ya no existe devuelve el mismo resultado (normalmente un 404) y no hace nada dos veces.

                                                                
HEAD — Igual que GET, pero la respuesta contiene solo cabeceras — no se devuelve ningún cuerpo. Use HEAD para comprobar si una URL existe, qué tamaño tiene un archivo (Content-Length), cuándo se modificó por última vez (Last-Modified) o de qué tipo es (Content-Type), sin descargar la carga completa.

                                                                
OPTIONS — Pregunta al servidor qué métodos y opciones están permitidos para una URL, o dispara una comprobación previa de CORS. Las cabeceras de la respuesta, como Access-Control-Allow-Methods, enumeran lo permitido. OPTIONS normalmente no lleva cuerpo; los navegadores suelen enviarlo automáticamente antes de un POST/PUT/PATCH/DELETE de origen cruzado.

                                                                
Fácil de confundir: HEAD frente a GET — la petición es idéntica, pero HEAD no devuelve cuerpo. PUT frente a PATCH — PUT reemplaza todo el recurso; PATCH aplica una actualización parcial solo de los campos que envía.