Probador de Solicitudes API

Probador de Solicitudes API - Probar APIs REST Online

Toda integración API empieza igual: lea la documentación, envíe una petición de prueba hecha a mano, inspeccione la respuesta, luego escriba código de producción solo una vez confirmado el contrato. Durante décadas ese flujo de trabajo ha significado Postman, Insomnia, curl o HTTPie — todos los cuales requieren instalar software. Esta herramienta pone el mismo flujo dentro de una pestaña del navegador para que pueda golpear un endpoint rápido sin dejar su contexto actual de desarrollo. Soporta cada verbo HTTP estándar (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), acepta cabeceras arbitrarias en forma JSON limpia (tokens Bearer de Authorization, X-API-Key, Content-Type, Accept-Language, cabeceras corporativas personalizadas), envía bodies JSON/XML/form-encoded/raw text, y le muestra todo lo que vuelve: código de estado numérico con la frase razón estándar, cada cabecera de respuesta parseada y etiquetada, el body pretty-printed si parsea como JSON o crudo si no, tiempo round-trip en milisegundos, y longitud en bytes de la respuesta. El obstáculo más común para test de API en navegador es CORS — las APIs públicas diseñadas para uso en navegador (Stripe, GitHub, OpenAI, JSONPlaceholder) funcionan bien, pero APIs internas que solo esperan tráfico servidor-a-servidor bloquearán la petición con una cabecera Access-Control-Allow-Origin faltante. Cuando ocurra, el mensaje de error le dice exactamente qué buscar en la configuración CORS de su servidor API.

¿Qué es un Probador de Solicitudes API?

Un Probador de Solicitudes API es una herramienta que le permite enviar solicitudes HTTP a APIs y ver sus respuestas. Es esencial para:

- Probar endpoints de API durante desarrollo
- Depurar problemas de API
- Explorar APIs de terceros
- Verificar autenticación y autorización
- Probar diferentes métodos HTTP
- Verificar formatos de respuesta de API

Actúa como un cliente que puede comunicarse con cualquier API REST, similar a herramientas como Postman o Insomnia.

¿Cómo pruebo una API?

Probar una API es simple:

1. Ingrese la URL del endpoint de API
2. Seleccione el método HTTP (GET, POST, PUT, DELETE, PATCH)
3. (Opcional) Agregue headers personalizados en formato JSON
4. (Opcional) Agregue cuerpo de solicitud para solicitudes POST/PUT/PATCH
5. Haga clic en 'Enviar Solicitud'
6. Vea el estado de respuesta, headers, cuerpo y tiempo

Ejemplo de solicitud GET:
URL: https://jsonplaceholder.typicode.com/users/1
Método: GET

Ejemplo de solicitud POST:
URL: https://jsonplaceholder.typicode.com/posts
Método: POST
Cuerpo: {"title": "Test", "body": "Content", "userId": 1}

¿Qué métodos HTTP son compatibles?

Esta herramienta admite todos los métodos HTTP estándar:

- GET: Recuperar datos del servidor
- POST: Enviar datos para crear nuevos recursos
- PUT: Actualizar recursos existentes completamente
- PATCH: Actualizar parcialmente recursos existentes
- DELETE: Eliminar recursos
- HEAD: Obtener solo headers (sin cuerpo)
- OPTIONS: Verificar métodos compatibles

La mayoría de APIs usan GET (leer), POST (crear), PUT/PATCH (actualizar) y DELETE.

¿Cómo agrego headers personalizados?

Los headers deben agregarse en formato JSON válido:

{
"Content-Type": "application/json",
"Authorization": "Bearer su-token-aquí",
"X-Custom-Header": "valor"
}

Headers comunes:
- Content-Type: Especifica formato del cuerpo de solicitud (application/json, text/xml)
- Authorization: Tokens de autenticación (Bearer, Basic, claves API)
- Accept: Formato de respuesta esperado
- User-Agent: Identificación del cliente
- X-API-Key: Autenticación con clave API

Los headers son pares clave-valor que proporcionan metadatos sobre la solicitud.

¿Qué son los errores CORS?

CORS (Intercambio de Recursos de Origen Cruzado) es un mecanismo de seguridad del navegador que puede bloquear solicitudes de API de esta herramienta:

- Muchas APIs no permiten solicitudes de navegadores
- Este es comportamiento de seguridad normal
- No es un problema con esta herramienta o su navegador
- Las APIs públicas a menudo tienen CORS habilitado
- Las APIs privadas pueden bloquear solicitudes de navegador

Soluciones:
- Use APIs que admitan CORS
- Pruebe con extensiones de navegador que deshabiliten CORS (solo para pruebas)
- Use herramientas backend para pruebas de producción
- Contacte a proveedores de API para habilitar CORS

Para pruebas de API serias, considere usar herramientas dedicadas como Postman, Insomnia o frameworks de prueba backend.

¿Cuándo usar PUT vs PATCH vs POST para actualizar un recurso?

Estos tres verbos parecen intercambiables a principiantes pero tienen semánticas distintas que determinan la corrección de la API y el comportamiento de caché. POST CREA un NUEVO recurso en el servidor (o dispara una acción con efectos secundarios) — el servidor elige el ID del nuevo recurso y devuelve su ubicación. Úselo para /users al registrar nuevo usuario, /orders al hacer pedido, /search al ejecutar búsqueda que modifica estado. PUT REEMPLAZA un recurso existente completo en una URL conocida — envía la representación nueva completa, y cualquier campo omitido se resetea a null/default. Úselo al actualizar el objeto perfil completo de usuario en /users/123. PATCH modifica parcialmente un recurso existente — envía solo los campos que cambian, dejando otros intactos. Úselo al cambiar solo el campo email en /users/123. La spec HTTP dice que PUT y PATCH deben ser IDEMPOTENTES (llamar al mismo PUT/PATCH dos veces produce el mismo estado final), mientras POST no necesita serlo (dos POST a /orders crean dos pedidos). Equivóquese aquí y los clientes reintentarán POSTs fallidos creando registros duplicados accidentalmente.

¿Cómo envío un token Bearer de Authorization correctamente?

La autenticación Bearer es el patrón dominante de auth API en 2026 — usado por OAuth 2.0, OpenID Connect, APIs basadas en JWT, y la mayoría de plataformas SaaS modernas. El formato es fijo por RFC 6750: el valor de la cabecera Authorization DEBE ser la palabra literal 'Bearer' seguida de exactamente un espacio y el string del token. En el campo Headers de esta herramienta, pegue:

{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U"
}

Errores comunes: (1) Olvidar el espacio tras 'Bearer' — APIs devuelven 401. (2) Usar minúscula 'bearer' — RFC dice insensible a mayúsculas pero algunos servidores estrictos lo rechazan. (3) Incluir los corchetes '<' '>' de ejemplos de docs literalmente en el token. (4) Enviar el token crudo sin prefijo 'Bearer' — ese es el patrón Basic auth antiguo. (5) Reutilizar un JWT expirado — decodifique en jwt.io para verificar el claim 'exp'. Nunca pegue tokens de producción en vivo en herramientas no confiables; este probador corre completamente en su navegador pero aún debería rotar cualquier token usado para debugging.

¿Qué significan los códigos de estado HTTP comunes (200, 201, 204, 301, 400, 401, 403, 404, 422, 429, 500, 503)?

El código de estado es lo primero que debe leer en cualquier respuesta — le dice el resultado antes incluso de mirar el cuerpo.

2xx éxito:
- 200 OK: la solicitud tuvo éxito, el cuerpo contiene el resultado.
- 201 Created: un POST creó un nuevo recurso; revise la cabecera Location para su URL.
- 204 No Content: éxito con cuerpo vacío (común en DELETE y algunos PUT/PATCH).

3xx redirección:
- 301 Moved Permanently: el recurso tiene nueva URL — actualice su endpoint.
- 302/307/308: redirecciones temporales o que preservan el método.

4xx error del cliente (su solicitud está mal):
- 400 Bad Request: sintaxis malformada o parámetros inválidos.
- 401 Unauthorized: auth ausente o inválida — revise su cabecera Authorization / token.
- 403 Forbidden: autenticado pero sin permiso (permisos/scopes).
- 404 Not Found: URL incorrecta o el recurso no existe.
- 422 Unprocessable Entity: el cuerpo se parseó bien pero falló las reglas de validación.
- 429 Too Many Requests: límite de tasa alcanzado — espere y revise la cabecera Retry-After.

5xx error del servidor (el servidor falló):
- 500 Internal Server Error: una excepción no manejada en el servidor.
- 503 Service Unavailable: servidor sobrecargado o en mantenimiento; reintente más tarde.

Regla práctica: 4xx significa corrija su solicitud, 5xx significa que la culpa es del servidor.

¿Necesito establecer una cabecera Content-Type al enviar un cuerpo de solicitud?

Sí — cuando envía un cuerpo, el servidor usa Content-Type para decidir cómo parsearlo, y equivocarse es una de las causas más comunes de una respuesta 400 o 415.

- Cuerpo JSON: establezca Content-Type a application/json. La mayoría de APIs JSON rechazan o ignoran silenciosamente un cuerpo enviado sin él. El cuerpo debe ser JSON válido, ej. {"name":"Ada"}.
- Datos de formulario: establezca application/x-www-form-urlencoded y envíe key=value&key2=value2 (el formato clásico de formularios HTML).
- Texto plano/XML: use text/plain o application/xml/text/xml para que el servidor no intente parsearlo como JSON.
- Subida de archivos: use multipart/form-data (nota: los límites multipart reales son más fáciles desde curl/Postman nativo que desde un campo de texto crudo).

Para GET, HEAD, OPTIONS y DELETE sin cuerpo, no necesita Content-Type en absoluto. Recuerde también que la cabecera Accept es el espejo de Content-Type: le dice al servidor qué formato quiere de vuelta (ej. Accept: application/json).

¿Cómo funciona la función Copiar como cURL?

Tras enviar una solicitud, haga clic en 'Copiar como cURL' para copiar un comando curl listo para ejecutar que reproduce exactamente lo que la herramienta acaba de enviar — misma URL, mismo método -X, un flag -H por cabecera, y un flag --data para el cuerpo. Péguelo en cualquier terminal, un reporte de bug, un runbook o un script de CI.

Este es el escape más útil del navegador. Como los navegadores aplican CORS, algunas APIs que bloquean este probador en el navegador funcionarán perfectamente desde curl, que no tiene política de mismo origen. Así que cuando choque con un muro CORS, convierta la solicitud a curl y ejecútela desde su terminal o servidor para confirmar que la API en sí funciona.

El comando generado entrecomilla y escapa la URL, las cabeceras y el cuerpo para que los valores con espacios o caracteres especiales se mantengan intactos. Es simple, sin dependencias y portable a cualquier shell, convirtiéndolo en el formato universal de intercambio entre este probador, sus compañeros y su automatización.

¿Mis datos están seguros?

Consideraciones de privacidad:

- Las solicitudes van directamente de su navegador a la API
- Ningún dato pasa por nuestros servidores
- No registramos ni almacenamos ningún dato de solicitud/respuesta
- Tenga cuidado con datos sensibles (contraseñas, tokens)
- Evite probar con credenciales de producción
- Considere usar endpoints de API de prueba/sandbox

Consejos de seguridad:
- No comparta claves API públicamente
- Use credenciales específicas del entorno
- Pruebe con datos ficticios cuando sea posible
- Revoque tokens de prueba después de usar

Características Clave

• Probar cualquier endpoint de API REST
• Soporte para todos los métodos HTTP (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)
• Agregar headers de solicitud personalizados
• Enviar cuerpo de solicitud (JSON, XML, texto)
• Ver códigos de estado de respuesta
• Mostrar headers de respuesta
• Mostrar cuerpo de respuesta formateado
• Medir tiempo de respuesta
• Calcular tamaño de respuesta
• Resaltado de sintaxis para respuestas JSON
• Copiar datos de respuesta al portapapeles
• Copiar cualquier solicitud como comando cURL listo para ejecutar
• Soporte de modo oscuro
• 100% del lado del cliente - las solicitudes van directamente a APIs
• Sin registro o almacenamiento de datos
• Diseño responsive amigable con móviles