How to Test REST APIs in Your Browser — A Developer's Guide

¿Qué son las pruebas de API?

Toda aplicación web y móvil moderna funciona sobre APIs. Cuando cargas tu feed de Twitter, haces un pedido en Amazon o consultas el clima en el teléfono, detrás hay una llamada a una API. Las pruebas de API consisten en enviar solicitudes a esos endpoints y comprobar que las respuestas son correctas: el código de estado adecuado, la forma de datos esperada y un rendimiento razonable.

A diferencia de las pruebas de interfaz, las pruebas de API atacan la capa bajo la interfaz. Detectan errores antes, se ejecutan más rápido y cubren escenarios difíciles de provocar con un clic en el navegador. Tanto si construyes tu propia API como si te integras con un servicio de terceros, saber probar endpoints con rapidez es una habilidad básica para cualquier desarrollador.

Métodos HTTP explicados

Las APIs REST usan métodos HTTP estándar para indicar la acción sobre un recurso. Referencia rápida:

Método	Propósito	¿Tiene cuerpo?
GET	Obtener un recurso o una colección	No
POST	Crear un recurso nuevo	Sí
PUT	Reemplazar un recurso por completo	Sí
PATCH	Actualizar parcialmente un recurso	Sí
DELETE	Eliminar un recurso	Rara vez

Diferencia clave: PUT reemplaza el recurso por completo: cualquier campo que omitas se eliminará. PATCH solo actualiza los campos que incluyes en el cuerpo de la solicitud. La mayoría de las APIs que aceptan actualizaciones usan PATCH para modificaciones parciales y PUT para reemplazos totales.

Cómo probar APIs en el navegador

No necesitas instalar Postman ni memorizar flags de cURL para probar una API. El Explorador de API en JSONTech.net te permite enviar solicitudes en modo Navegador para APIs con CORS habilitado o cambiar al modo Proxy cuando el navegador bloquee la solicitud. Así:

1. Abre la herramienta Explorador de API.
2. Elige el método HTTP (GET, POST, PUT, PATCH o DELETE) en el menú desplegable.
3. Introduce la URL del endpoint. Por ejemplo: https://jsonplaceholder.typicode.com/posts/1
4. Añade los encabezados que necesites (como Content-Type o Authorization).
5. Si el método requiere cuerpo (POST, PUT, PATCH), escribe tu payload JSON en el editor del cuerpo.
6. Pulsa Enviar y revisa la respuesta: código de estado, encabezados y el cuerpo JSON formateado.

Si el navegador muestra un error de CORS, cambia el Explorador de API al modo Proxy. Así la solicitud real pasa por la infraestructura edge de JSONTech para que puedas seguir probando sin salir de la página.

Ejemplo: obtener una publicación

GET https://jsonplaceholder.typicode.com/posts/1

Response (200 OK):
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\\nsuscipit recusandae consequuntur..."
}

Ejemplo: crear una publicación

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json

{
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Response (201 Created):
{
  "id": 101,
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Entender los encabezados de la solicitud

Los encabezados llevan metadatos sobre la solicitud. Indican al servidor qué formato esperas, quién eres y cómo debe comportarse la conexión. Los que más usarás:

Encabezado	Propósito	Valor de ejemplo
Content-Type	Formato del cuerpo de la solicitud	application/json
Accept	Formato deseado en la respuesta	application/json
Authorization	Credenciales de autenticación	Bearer eyJhbGciOi...
Cache-Control	Directivas de caché	no-cache
User-Agent	Identifica la aplicación cliente	MyApp/1.0

Olvidar Content-Type: application/json en solicitudes POST/PUT es una de las causas más frecuentes de que las APIs respondan 400 Bad Request. Sin él, el servidor no sabe cómo interpretar el cuerpo.

Métodos de autenticación

La mayoría de las APIs en producción exigen autenticación. Los tres patrones más habituales:

Bearer Token (JWT)

El enfoque más común en APIs modernas. Incluyes un token en el encabezado Authorization:

{
  "headers": {
    "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    "Content-Type": "application/json"
  }
}

Autenticación básica

Codifica el usuario y la contraseña como una cadena Base64. Es simple pero solo es segura sobre HTTPS:

{
  "headers": {
    "Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ=",
    "Content-Type": "application/json"
  }
}

Clave de API

Algunas APIs usan un encabezado personalizado o un parámetro de consulta para una clave estática:

// Como encabezado
{
  "headers": {
    "X-API-Key": "sk_live_abc123def456"
  }
}

// Como parámetro de consulta
GET https://api.example.com/data?api_key=sk_live_abc123def456

Leer las respuestas de la API

Al enviar una solicitud, la respuesta te dice exactamente qué ocurrió. Debes leer tres cosas: el código de estado, los encabezados de respuesta y el cuerpo.

Códigos de estado

Código	Significado	Cuándo lo verás
200	OK	GET, PUT, PATCH o DELETE correctos
201	Creado	POST correcto que creó un recurso
400	Solicitud incorrecta	JSON inválido, campos obligatorios ausentes, tipos incorrectos
401	No autorizado	Token de autenticación ausente o vencido
403	Prohibido	Credenciales válidas pero permisos insuficientes
404	No encontrado	El endpoint o el recurso no existe
500	Error interno del servidor	Fallo en el lado del servidor

Encabezados de respuesta

Presta atención a encabezados como Content-Type (confirma el formato de la respuesta), X-RateLimit-Remaining (cuántas solicitudes te quedan) y Retry-After (cuándo reintentar tras alcanzar un límite de tasa).

Cuerpo JSON

El cuerpo de la respuesta es donde viven los datos. Una API bien diseñada lo envuelve en una estructura coherente:

{
  "data": {
    "id": 42,
    "name": "Widget",
    "price": 9.99
  },
  "meta": {
    "request_id": "req_8f3a2b"
  }
}

Cuando algo falla, recibes un objeto de error en lugar de uno de datos. Comprueba siempre primero el código de estado y luego interpreta el cuerpo en consecuencia.

CORS: qué es y por qué ves errores

Cross-Origin Resource Sharing (CORS) es un mecanismo de seguridad del navegador. Cuando tu JavaScript en localhost:3000 intenta llamar a una API en api.example.com, el navegador bloquea la solicitud a menos que el servidor lo permita explícitamente mediante encabezados CORS.

El error típico se parece a:

Access to fetch at 'https://api.example.com/data' from origin
'http://localhost:3000' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

No es un error en tu código: es el navegador aplicando seguridad. Soluciones habituales:

• Pedir al dueño de la API que añada tu origen a su encabezado Access-Control-Allow-Origin.
• Usar un proxy — enrutar las solicitudes por tu propio backend para evitar por completo la restricción entre orígenes.
• Usar una herramienta basada en navegador con opción de proxy como el Explorador de API. Empieza en modo Navegador con APIs abiertas y cambia al modo Proxy cuando necesites que JSONTech retransmita la solicitud para probarla.

CORS solo afecta a los navegadores. Herramientas como cURL, Postman y el código del lado del servidor no están sujetas a restricciones CORS.

Errores frecuentes al probar APIs

1. Olvidar el encabezado Content-Type. Enviar un cuerpo JSON sin Content-Type: application/json hace que muchos servidores rechacen o interpreten mal la solicitud.
2. Usar GET cuando quieres decir POST. Las solicitudes GET no deben llevar cuerpo.
3. Ignorar los códigos de estado. Un 200 con un mensaje de error en el cuerpo no es un éxito.
4. Incrustar credenciales en la URL. No pongas claves de API ni tokens en la cadena de consulta si puedes usar encabezados.
5. Probar solo el camino feliz. Envía JSON mal formado, cuerpos vacíos, campos obligatorios ausentes y tokens inválidos.
6. No revisar los límites de tasa. Muchas APIs responden 429 cuando superas el límite.
7. Confundir errores CORS con errores del servidor. Un error CORS significa que el navegador bloqueó la solicitud.

Pruébalo tú

¿Listo para probar una API? Abre el Explorador de API y envía una solicitud GET a https://jsonplaceholder.typicode.com/users/1. Verás la respuesta completa — código de estado, encabezados y cuerpo JSON formateado — y, si otra API queda bloqueada por CORS, podrás reintentarlo en modo Proxy.

Sin descargas, sin registros, sin configuración. Solo elige un método, escribe una URL y pulsa Enviar.