En esta clase vas a practicar cómo leer e interpretar una API REST antes de consumirla desde Vue. Trabajarás con URLs, verbos HTTP, respuestas JSON y la herramienta Postman para probar peticiones manualmente.
Nos enfocaremos en lo esencial:
- URL, recurso y parámetros: cómo se compone una petición HTTP.
- Verbos HTTP (
GET,POST,PUT,PATCH,DELETE) y su relación con CRUD. - Respuestas JSON: cómo leer la estructura y acceder a los datos desde JavaScript.
- Postman: probar endpoints manualmente con headers y body.
- Documentación básica de endpoints REST.
Usaremos como API de práctica Reqres, que es gratuita y no requiere registro (solo un header simple).
Concepto: una petición HTTP se compone de una URL (que apunta a un recurso), parámetros opcionales (query string después del ?), un verbo HTTP (GET, POST, etc.) y, opcionalmente, headers y body. Antes de programar, conviene leer la URL y saber qué le estás pidiendo al servidor.
Objetivo: reconocer los elementos básicos de una petición HTTP a partir de su URL.
Instrucciones:
Analiza las siguientes URLs:
https://reqres.in/api/users?page=1https://reqres.in/api/users/2https://reqres.in/api/unknownhttps://reqres.in/api/users?page=2
Para cada una, responde:
- ¿Cuál es el recurso principal?
- ¿La URL tiene parámetros?
- Si tiene parámetros, ¿cuáles son?
- ¿Qué método HTTP usarías para consultar esa URL?
- ¿Qué tipo de información esperas recibir?
Completa una tabla siguiendo este ejemplo:
| URL | Recurso | Parámetros | Método HTTP | Respuesta esperada |
|---|---|---|---|---|
https://reqres.in/api/users?page=1 |
users | page=1 | GET | Lista de usuarios de la página 1 |
💡 Pista: todo lo que viene después de
?son query params (parámetros de consulta), separados por&. Si la URL termina en/algo/2, ese2suele ser un path param (identificador del recurso), no un query param.
Resultado esperado: una tabla con las cuatro URLs analizadas y diferenciando claramente recursos, parámetros y método.
Concepto: CRUD es el acrónimo de las cuatro operaciones básicas sobre datos: Create, Read, Update, Delete. En una API REST cada operación se mapea a un verbo HTTP estándar: POST crea, GET lee, PUT/PATCH actualizan, DELETE elimina.
Objetivo: comprender la relación entre CRUD y los principales verbos HTTP.
Instrucciones:
Relaciona cada acción con el verbo HTTP más adecuado:
- Obtener la lista de usuarios.
- Obtener un usuario específico.
- Crear un nuevo usuario.
- Reemplazar completamente los datos de un usuario.
- Actualizar solo una parte de los datos de un usuario.
- Eliminar un usuario.
Verbos disponibles: GET, POST, PUT, PATCH, DELETE.
Luego completa la siguiente tabla:
| Acción | Operación CRUD | Verbo HTTP | Endpoint sugerido |
|---|---|---|---|
| Obtener lista de usuarios | READ | GET | /api/users |
| Obtener usuario con id 2 | |||
| Crear usuario | |||
| Reemplazar usuario con id 2 | |||
| Actualizar parcialmente usuario con id 2 | |||
| Eliminar usuario con id 2 |
Pregunta final: explica con tus palabras la diferencia entre PUT y PATCH.
💡 Pista: piensa en
PUTcomo "te paso el objeto entero, sobreescribe todo" y enPATCHcomo "te paso solo los campos que cambian". Si solo quieres actualizar el email de un usuario,PATCHes más conveniente porque no necesitas reenviar el resto de propiedades.
Resultado esperado: la tabla completa y una explicación breve de la diferencia entre PUT y PATCH.
Concepto: las APIs REST suelen responder en formato JSON. Para consumir esos datos desde JavaScript necesitas saber navegar la estructura: distinguir objetos {} de arrays [], acceder por propiedad con . y por índice con [].
Objetivo: interpretar la estructura de una respuesta JSON y reconocer cómo acceder a sus datos desde JavaScript.
Instrucciones:
Observa el siguiente JSON (es la respuesta real de GET /api/users?page=1):
{
"page": 1,
"per_page": 6,
"total": 12,
"total_pages": 2,
"data": [
{
"id": 1,
"email": "george.bluth@reqres.in",
"first_name": "George",
"last_name": "Bluth",
"avatar": "https://reqres.in/img/faces/1-image.jpg"
},
{
"id": 2,
"email": "janet.weaver@reqres.in",
"first_name": "Janet",
"last_name": "Weaver",
"avatar": "https://reqres.in/img/faces/2-image.jpg"
}
]
}- ¿Qué tipo de dato es
data? - ¿Cuántos usuarios aparecen dentro de
data? - ¿Qué propiedad contiene el correo de cada usuario?
- ¿Qué propiedad usarías como identificador único?
- ¿Qué propiedad usarías para mostrar una imagen del usuario?
- ¿Cómo accederías al correo del primer usuario usando JavaScript?
- ¿Cómo accederías al nombre del segundo usuario usando JavaScript?
- ¿Qué dato usarías como
keysi luego recorres estos usuarios conv-foren Vue?
Suponiendo que la respuesta está guardada en una variable respuesta, completa:
// Correo del primer usuario
respuesta.data[0].______;
// Nombre del segundo usuario
respuesta.data[1].______;
// ID del primer usuario
respuesta.data[0].______;💡 Pista: las llaves
{}representan un objeto (acceso con.propiedad) y los corchetes[]un array (acceso con[indice], empezando en 0). El primer usuario esdata[0], nodata[1]. Parav-forsiempre elige un identificador único y estable comoid, nunca el índice si los elementos pueden cambiar de orden.
Resultado esperado: preguntas respondidas y los tres respuesta.data[…] completos con la propiedad correcta.
Concepto: Postman es una herramienta que permite enviar peticiones HTTP sin escribir código. Es ideal para explorar una API antes de consumirla desde Vue: verificas qué responde, qué status code devuelve y qué headers necesita. Si la petición no funciona en Postman, tampoco va a funcionar en tu app.
Objetivo: realizar peticiones HTTP manualmente con Postman antes de consumir la API desde Vue.
Instrucciones:
Abre Postman y realiza las siguientes peticiones a la API de Reqres.
⚠️ Importante: Reqres exige un header en todas las peticiones. Agrégalo siempre antes de enviar:
- Key:
x-api-key- Value:
reqres-free-v1
- Método:
GET - URL:
https://reqres.in/api/users?page=1
Responde:
- ¿Qué status code recibiste?
- ¿Qué significa ese status?
- ¿Dónde aparece la lista de usuarios?
- ¿Cuántos usuarios devuelve la respuesta?
- Copia el email del primer usuario.
- Método:
GET - URL:
https://reqres.in/api/users/2
Responde:
- ¿Qué status code recibiste?
- ¿Qué usuario devuelve la API?
- ¿Qué diferencia tiene esta respuesta con la petición anterior?
- Método:
POST - URL:
https://reqres.in/api/users
En Body selecciona raw y luego JSON, y envía:
{
"name": "morpheus",
"job": "leader"
}Responde:
- ¿Qué status code recibiste?
- ¿Qué significa ese status?
- ¿Qué datos devuelve la API?
- ¿Qué diferencia hay entre enviar datos por URL y enviarlos por body?
💡 Pista: los status code más comunes son:
200 OK(lectura correcta),201 Created(recurso creado),204 No Content(acción correcta, sin cuerpo de respuesta),400 Bad Request(datos mal formados),401 Unauthorized(falta auth),404 Not Found(recurso inexistente). Si te llega401, casi siempre olvidaste el headerx-api-key.
Resultado esperado: las tres peticiones ejecutadas en Postman, con sus status code y respuestas anotadas.
Concepto: documentar una API significa describir, para cada endpoint, qué hace, qué necesita y qué responde. Una buena documentación permite que cualquier persona del equipo consuma la API sin tener que adivinar.
Objetivo: crear una documentación simple de endpoints REST a partir de lo probado en Postman.
Instrucciones:
Usando lo que probaste en el ejercicio anterior, completa la siguiente tabla:
| Método | Endpoint | Descripción | ¿Usa headers? | ¿Usa body? | Status esperado | Operación CRUD |
|---|---|---|---|---|---|---|
| GET | /api/users?page=1 |
Obtiene usuarios paginados | Sí | No | 200 | READ |
| GET | /api/users/2 |
|||||
| POST | /api/users |
|||||
| PUT | /api/users/2 |
|||||
| DELETE | /api/users/2 |
💡 Pista: si no recuerdas qué status devuelve cada uno, vuelve a Postman y pruébalo. Documentar sin verificar suele llevar a errores. Para Reqres:
GET→ 200,POST→ 201,PUT→ 200,DELETE→ 204.
Realiza una petición DELETE en Postman:
- Método:
DELETE - URL:
https://reqres.in/api/users/2 - Header:
x-api-key: reqres-free-v1
Responde:
- ¿Qué status code recibiste?
- ¿La respuesta trae body?
- ¿Qué significa que una eliminación pueda responder sin contenido?
- ¿Qué operación CRUD representa?
- ¿Por qué es importante probar estos endpoints antes de escribir código en Vue?
💡 Pista:
204 No Contentsignifica "se hizo lo que pediste, pero no tengo nada que devolverte". Es habitual enDELETE: ya no hay recurso que mostrar, así que la respuesta viene vacía. No es un error.
Resultado esperado: la tabla del ejercicio 5 completa y el DELETE ejecutado con sus preguntas respondidas.