Skip to content

Instantly share code, notes, and snippets.

@wh01s17
Created May 25, 2026 21:06
Show Gist options
  • Select an option

  • Save wh01s17/a590fd462af65e089c9d69f2262fa190 to your computer and use it in GitHub Desktop.

Select an option

Save wh01s17/a590fd462af65e089c9d69f2262fa190 to your computer and use it in GitHub Desktop.
Ejercicios - Fundamentos de consumo de APIs

Ejercicios - Fundamentos de consumo de APIs

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).


Ejercicio 1 - Identificar las partes de una petición HTTP

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:

  1. https://reqres.in/api/users?page=1
  2. https://reqres.in/api/users/2
  3. https://reqres.in/api/unknown
  4. https://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, ese 2 suele 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.


Ejercicio 2 - Relacionar CRUD con verbos HTTP

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:

  1. Obtener la lista de usuarios.
  2. Obtener un usuario específico.
  3. Crear un nuevo usuario.
  4. Reemplazar completamente los datos de un usuario.
  5. Actualizar solo una parte de los datos de un usuario.
  6. 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 PUT como "te paso el objeto entero, sobreescribe todo" y en PATCH como "te paso solo los campos que cambian". Si solo quieres actualizar el email de un usuario, PATCH es 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.


Ejercicio 3 - Leer e interpretar una respuesta JSON

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"
        }
    ]
}

Preguntas

  • ¿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 key si luego recorres estos usuarios con v-for en Vue?

Respuestas esperadas en JavaScript

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 es data[0], no data[1]. Para v-for siempre elige un identificador único y estable como id, nunca el índice si los elementos pueden cambiar de orden.

Resultado esperado: preguntas respondidas y los tres respuesta.data[…] completos con la propiedad correcta.


Ejercicio 4 - Probar una API con Postman

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

Petición 1 - Listar usuarios

  • 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.

Petición 2 - Obtener un usuario específico

  • 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?

Petición 3 - Crear un usuario

  • 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 llega 401, casi siempre olvidaste el header x-api-key.

Resultado esperado: las tres peticiones ejecutadas en Postman, con sus status code y respuestas anotadas.


Ejercicio 5 - Documentar endpoints de una API

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 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.

Desafío final

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 Content significa "se hizo lo que pediste, pero no tengo nada que devolverte". Es habitual en DELETE: 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment