Preguntas y respuestas sobre la API REST (Guía 2026)

Las API REST impulsan la mayoría de las integraciones de Internet. Tanto si solicitas un puesto de backend, un puesto de full stack o un puesto de ingeniería de software, es probable que te hagan preguntas sobre el diseño de API REST, los métodos HTTP y los patrones de autenticación.

En esta guía, te explicaré las preguntas que realmente hacen los entrevistadores. Los he organizado por nivel de dificultad y tipo de función, para que puedas centrarte en lo que más importa para el puesto al que aspiras. Cada respuesta incluye ejemplos prácticos y, cuando procede, fragmentos de código que puedes adaptar.

Hay que tener en cuenta una cosa: los entrevistadores evalúan los conceptos básicos con mucha más frecuencia que los temas avanzados. Si dominas los conceptos básicos (métodos HTTP, códigos de estado, ausencia de estado), podrás afrontar con confianza la mayoría de las entrevistas sobre API REST. Los elegantes patrones arquitectónicos llegaron más tarde.

Preguntas básicas sobre la API REST en una entrevista de trabajo

Estas preguntas evalúan tus conocimientos básicos. Espera que te las hagan en casi todas las entrevistas, independientemente del nivel jerárquico.

1. ¿Qué es REST y cuáles son sus limitaciones?

REST son las siglas de Representational State Transfer (transferencia de estado representacional). Es un estilo arquitectónico para diseñar aplicaciones en red, definido por Roy Fielding en su tesis doctoral del año 2000.

REST tiene seis restricciones:

1. Cliente-servidor: Separación de responsabilidades entre la interfaz de usuario y el almacenamiento de datos.
2. : Cada solicitud contiene toda la información necesaria para completarla.
3. Almacenable en caché: Las respuestas deben indicar si pueden almacenarse en caché.
4. Sistema por capas: Los componentes no pueden ver más allá de su capa inmediata.
5. Interfaz uniforme: Forma estandarizada de interactuar con los recursos
6. Código bajo demanda (opcional): Los servidores pueden enviar código ejecutable a los clientes.

2. ¿Cuál es la diferencia entre REST y SOAP?

REST es un estilo arquitectónico; SOAP es un protocolo. REST suele utilizar JSON sobre HTTP y aprovecha los métodos HTTP estándar. SOAP utiliza exclusivamente XML y define su propio formato de mensajería con sobres y los encabezados.

SOAP sigue teniendosentido para los sistemas empresariales que requieren contratos formales (WSDL) o seguridad a nivel de mensajes (WS-Security).

3. ¿Qué son los métodos HTTP y cuándo se utiliza cada uno?

Los métodos HTTP definen la acción que se va a realizar sobre un recurso.

4. ¿Cuál es la diferencia entre PUT y POST?

POST crea un nuevo recurso en el que el servidor determina el URI. PUT sustituye un recurso en una URI específica que tú especificas.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource

Si realizas un PUT a una URI que no existe, el servidor puede crearla. Si realizas un PUT a un URI existente, reemplazarás todo el recurso.

5. ¿Cuál es la diferencia entre PUT y PATCH?

PUT reemplaza todo el recurso. PATCH aplica modificaciones parciales.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "khalid@example.com", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}

6. ¿Qué significa «sin estado» en REST?

Sin estado significa que cada solicitud debe contener toda la información que el servidor necesita para procesarla. El servidor no almacena ningún contexto del cliente entre solicitudes.

Esto significa que no hay sesiones del lado del servidor. Si un usuario está autenticado, el cliente debe enviar credenciales (normalmente un token) con cada solicitud.

7. ¿Qué hace que una API sea RESTful?

Una API es verdaderamente RESTful cuando cumple todas las restricciones REST, incluyendo HATEOAS (Hypermedia as the Engine of Application State). En la práctica, la mayoría de las API que se autodenominan «REST» son en realidad «similares a REST» o se encuentran en el nivel 2 del modelo de madurez de Richardson. Y, sinceramente, eso está bien para la mayoría de los casos de uso.

Niveles del modelo de madurez de Richardson para API REST. Imagen del autor.

8. ¿Cuáles son los códigos de estado HTTP básicos que debes conocer?

Debes estar familiarizado al menos con estos siete códigos de estado esenciales que cubren la mayoría de los escenarios de API:

9. ¿Cuál es la diferencia entre un recurso y un punto final?

Un recurso es la entidad de datos (usuario, pedido, producto). Un punto final es la ruta URL que proporciona acceso a ese recurso.

Resource: User
Endpoints: GET /users, GET /users/123, POST /users

10. ¿Cuáles son las mejores prácticas para el diseño de URI?

Utiliza sustantivos, no verbos. Mantén las URI en minúsculas con guiones para los nombres de varias palabras. Utiliza sustantivos en plural para referirte a colecciones.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items

Evita el anidamiento profundo. En lugar de /users/123/posts/456/comments/789, considera /comments/789 o /comments?post_id=456.

11. ¿Qué es la idempotencia y qué métodos HTTP son idempotentes?

Una operación es idempotente si al realizarla varias veces se obtieneel mismo resultado que al realizarla una sola vez.

Un PATCH que establece un valor esidempotente; un PATCH que incrementa un contador no lo es.

12. ¿Cuál es la diferencia entre métodos seguros e idempotentes?

Los métodos seguros no modifican los recursos (GET, HEAD, OPTIONS). Los métodos idempotentes pueden invocarse varias veces con el mismo efecto (GET, PUT, DELETE).

Todos los métodos seguros son idempotentes, pero no todos los métodos idempotentes son seguros. DELETE es idempotente, pero no seguro, ya que modifica el estado.

13. ¿Cuándo debes utilizar parámetros de consulta frente a parámetros de ruta?

Los parámetros de ruta identifican un recurso específico. Los parámetros de consulta filtran, ordenan o paganizan colecciones.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10

14. ¿Qué es la negociación de contenido?

La negociación de contenido permite a los clientes solicitar diferentes representaciones de un recurso. El cliente envía un encabezado « Accept » y el servidor responde con el formato adecuado.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML

15. ¿Cuál es el propósito del método OPTIONS?

OPTIONS devuelve los métodos HTTP que admite un servidor para una URL específica. Los navegadores lo utilizan para las solicitudes CORS preflight con el fin de comprobar si se permiten las solicitudes de origen cruzado.

Preguntas intermedias sobre la API REST en entrevistas de trabajo

Estas preguntas evalúan la aplicación práctica y la toma de decisiones. Esperadlos para puestos de nivel medio.

16. ¿Cuál es la diferencia entre 401 y 403?

Este es el par de códigos de estado que más confusión genera. He visto a ingenieros sénior confundirlos en revisiones de código.

401 No autorizado

Significa «sin autenticar». El servidor no sabe quién eres. Tu respuesta debería solicitar al usuario que inicie sesión.

403 Prohibido

Significa «no autorizado». El servidor sabe quién eres, pero no tienes permiso. Volver a autenticarse no servirá de nada.

Diagrama del flujo de decisión entre error de autenticación y error de autorización. Imagen del autor.

17. ¿Cuál es la diferencia entre 400 y 422?

Aquí hay algunos ejemplos que ilustran la diferencia:

400 Solicitud incorrecta

Esto indica una sintaxis mal formada. El servidor no puede analizar la solicitud (estructura JSON no válida, faltan encabezados obligatorios).

422 Entidad no procesable

Esto indica una sintaxis válida pero errores semánticos. El JSON es válido, pero los datos no superan la validación (formato de correo electrónico no válido, contraseña demasiado corta).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation

18. ¿Cuándo debes utilizar el código 409 Conflict?

Utiliza 409 cuando la solicitud entre en conflicto con el estado actual del recurso:

• Fallos de bloqueo optimista (discrepancia de ETag)
• Violaciones de restricciones únicas (nombre de usuario duplicado)
• Transiciones de estado no válidas (cancelación de un pedido ya enviado)

19. ¿Cómo se implementa la paginación?

Dos enfoques principales:

Paginación basada en desplazamiento

Es sencillo, pero tiene problemas de rendimiento con conjuntos de datos grandes.

GET /users?limit=20&offset=40

Paginación basada en el cursor

Se adapta mejor y evita la «deriva de la página» cuando cambian los datos.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ

Empresas como Stripe, GitHub y Slack utilizan la paginación basada en el cursor para grandes conjuntos de datos.

20. ¿Cuáles son las estrategias más comunes para el control de versiones de las API?

Hay tres enfoques principales, cada uno con diferentes ventajas e inconvenientes:

Versiones de URI

Este es el más común. Es explícito y fácil de depurar.

GET /v1/users
GET /v2/users

Versiones de encabezados

URL más limpias, pero más difíciles de probar en los navegadores.

GET /users
Accept-Version: v2

Versiones de los parámetros de consulta

Fácil de añadir, pero satura las URL.

GET /users?version=2

21. ¿Qué es un ETag y cómo funciona el almacenamiento en caché?

Un ETag es un identificador de versión de un recurso. El servidor lo envía en las respuestas; el cliente lo devuelve en las solicitudes posteriores para comprobar si el recurso ha cambiado.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)

22. ¿Qué métodos de autenticación se utilizan para las API REST?

Los cuatro métodos de autenticación más comunes son las claves API, los tokens de portador, OAuth 2.0 y JWT:

23. ¿Qué es JWT y cómo funciona?

El JWT (JSON Web Token) consta de tres partes: Encabezado, carga útil y firma. Más información sobre cómo trabajar con JSON en Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)

El servidor firma el token; los clientes lo envían con las solicitudes. El servidor valida la firma sin consultar la base de datos.

24. ¿Cuál es la diferencia entre RS256 y HS256?

HS256 (simétrico): El mismo secreto firma y verifica. Riesgo si varios servicios necesitan verificar los tokens.

RS256 (asimétrico): La clave privada firma, la clave pública verifica. Recomendado para sistemas distribuidos en los que varios servicios validan tokens.

25. ¿Qué es HATEOAS?

HATEOAS (Hypermedia as the Engine of Application State, hipermedia como motor del estado de la aplicación) significa que las respuestas incluyen enlaces a acciones y recursos relacionados.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}

En la práctica, la mayoría de las API no implementan HATEOAS por completo. Conoce el concepto, pero no esperes poder aplicarlo en la mayoría de los trabajos. Incluso las grandes empresas tecnológicas rara vez crean API que cumplan totalmente con HATEOAS.

26. ¿Cómo gestionas los errores de forma coherente?

Utiliza el formato RFC 7807 Problem Details para obtener respuestas de error coherentes:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}

27. ¿Qué es la limitación de velocidad y por qué es importante?

La limitación de velocidad protege tu API contra el uso indebido y garantiza un uso justo. Respuesta habitual:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

28. ¿Cómo diseñas el filtrado y la clasificación?

Utiliza parámetros de consulta con convenciones claras:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name

Preguntas avanzadas sobre la API REST en entrevistas de trabajo

Estas preguntas ponen a prueba el pensamiento arquitectónico. Esperadlos para puestos de alta dirección.

29. ¿Qué ha cambiado entre OAuth 2.0 y OAuth 2.1?

OAuth 2.1 consolida las mejores prácticas de seguridad:

Conclusión clave: utiliza el flujo de código de autorización con PKCE para todos los tipos de clientes.

30. ¿Cómo implementas la idempotencia para los puntos finales de pago?

Utiliza claves idempotentes para que las solicitudes POST sean seguras en caso de reintentos:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result

El cliente genera un UUID y lo envía junto con la solicitud. Si vuelve a llegar la misma clave, devuelve la respuesta almacenada en caché.

31. ¿Cómo diseñarías un limitador de velocidad distribuido?

En los sistemas distribuidos, no puedes utilizar contadores en memoria porque el tráfico se equilibra entre las distintas instancias. Esta es una trampa habitual que hace tropezar a los candidatos.

Arquitectura:

1. Utiliza Redis para el almacenamiento centralizado de contadores.
2. Implementar el algoritmo Token Bucket para la tolerancia a ráfagas.
3. Utiliza operaciones atómicas (scripts Lua) para evitar condiciones de carrera.

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429

32. ¿Cuándo elegirías gRPC en lugar de REST?

Elige gRPC para:

• Comunicación interna entre microservicios (mejora del rendimiento entre 5 y 10 veces)
• Requisitos de transmisión en tiempo real
• De móvil a backend con restricciones de ancho de banda
• Entornos políglotas que requieren contratos estrictos

Elige REST para:

• API públicas con consumidores diversos
• Aplicaciones web (compatibilidad universal con navegadores)
• Operaciones CRUD simples
• Equipos que no están familiarizados con Protocol Buffers

33. ¿Cómo gestionas las operaciones de larga duración?

Utiliza el patrón de solicitud asíncrona:

1. El cliente envía una solicitud.

2. El servidor devuelve 202 Accepted con una URL de estado.

3. El cliente consulta la URL de estado hasta que se completa.

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}

34. ¿Qué es el patrón Saga?

Saga gestiona transacciones distribuidas entre microservicios sin bloqueos. Cada servicio ejecuta una transacción local y publica un evento. Si un paso falla, las transacciones compensatorias deshacen los pasos anteriores.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order

35. ¿Cuáles son las vulnerabilidades de seguridad más comunes de JWT?

Confusión del algoritmo El atacante cambia RS256 a HS256 y firma con la clave pública. Solución: incluye siempre los algoritmos en la lista blanca.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])

Algoritmo «ninguno»: El atacante elimina la firma por completo. Solución: rechazar el algoritmo «ninguno».

Preguntas sobre API REST para programadores backend

36. ¿Qué es el problema de la consulta N+1?

El problema N+1 se produce cuando se recuperan N registros y luego se ejecuta una consulta independiente para cada relación de los registros.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries

Soluciones:

Django: Utiliza select_related() para claves externas y prefetch_related() para relaciones muchos a muchos.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()

SQLAlchemy: Utiliza joinedload() o selectinload().

37. ¿Cómo se configura el agrupamiento de conexiones?

El agrupamiento de conexiones reutiliza las conexiones a la base de datos en lugar de crear otras nuevas para cada solicitud.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)

38. ¿Qué estrategias de almacenamiento en caché conoces?

Existen tres estrategias principales de almacenamiento en caché, cada una optimizada para diferentes patrones de acceso:

39. ¿Cómo se implementa la verificación de firmas webhook?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

40. ¿Qué métricas indican el estado de la API?

Debes supervisar estas cuatro métricas clave para evaluar el estado de tu API:

Preguntas sobre API REST para programadores full stack

41. ¿Cuándo envía un navegador una solicitud CORS preflight?

Los navegadores envían una solicitud previa OPTIONS para:

• Métodos distintos de GET, HEAD, POST
• Encabezados personalizados (Autorización, X-API-Key)
• Tipo de contenido distinto de form-urlencoded, multipart/form-data, text/plain

42. ¿Cómo se configura CORS de forma segura?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Nunca utilices comodines (*) con credenciales. Nunca permitas un origen null.

43. ¿Dónde debes almacenar los tokens en el cliente?

El almacenamiento de tokens implica compromisos de seguridad entre las vulnerabilidades XSS y CSRF.

Mejores prácticas: Almacenalos tokens de actualizaciónen cookies HttpOnly con SameSite=Strict. Mantén los tokens de acceso en la memoria.

44. ¿Cuándo se debe utilizar WebSockets en lugar de SSE?

La elección depende de si necesitas comunicación bidireccional y de cómo deseas gestionar la reconexión:

Utiliza SSE para notificaciones, transmisiones en directo y cotizaciones bursátiles. Utiliza WebSockets para chats, juegos multijugador y edición colaborativa.

45. ¿Cómo gestionas la subida de archivos?

Para archivos grandes, utiliza cargas por partes con seguimiento del progreso:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}

Preguntas sobre la API REST basadas en escenarios

46. Diseña una API REST para un sistema de reservas hoteleras.

Recursos:

• /hotels - Lista y búsqueda de hoteles

• /hotels/{id}/rooms - Habitaciones disponibles

• /bookings - Crear y gestionar reservas.

• /guests/{id} - Perfiles de los huéspedes

Decisiones clave:

• Utiliza la paginación basada en el cursor para buscar hoteles.
• Implementar bloqueo optimista para la disponibilidad de habitaciones.
• Devuelve 409 Conflicto por intentos de doble reserva.
• Utiliza claves idempotentes para el procesamiento de pagos.

47. ¿Cómo implementarías las eliminaciones temporales?

Añadir una deleted_at marca de tiempo en lugar de eliminar registros:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()

48. ¿Cómo se migra de la versión 1 a la versión 2 sin afectar a los clientes?

Utiliza el patrón Strangler Fig:

1. Implementa la versión 2 junto con la versión 1.
2. Dirigir las nuevas funciones a la versión 2.
3. Migrar gradualmente los puntos finales existentes.
4. Comunicar la obsolescencia mediante el encabezado Sunset.
5. Eliminar la versión 1 tras el periodo de migración.

49. ¿Cómo diseñarías una API de búsqueda con filtrado complejo?

Para una búsqueda de productos con varios filtros:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123

Decisiones de diseño:

• Utiliza Elasticsearch para la búsqueda de texto completo (las bases de datos relacionales tienen dificultades con la coincidencia aproximada).
• Implementa la búsqueda por facetas para mostrar las opciones de filtro disponibles.
• Devuelve el recuento de filtros para que los usuarios sepan cuántos resultados produce cada filtro.
• Almacenar en caché las combinaciones de búsqueda más populares

50. ¿Cómo gestionas las versiones de las API en una arquitectura de microservicios?

Opciones:

1. Control de versiones a nivel de puerta de enlace: La puerta de enlace API redirige /v1/* a los servicios antiguos y /v2/* a los nuevos.

2. Versiones de nivel de servicio: Cada servicio gestiona su propia negociación de versiones.

3. Contratos orientados al consumidor: Utiliza Pact o herramientas similares para garantizar la compatibilidad.

Para la mayoría de los equipos, el control de versiones a nivel de puerta de enlace proporciona la separación más clara.

51. ¿Cómo implementarías la limitación de velocidad para los diferentes niveles de usuarios?

La solución consiste en definir límites específicos para cada nivel y comprobarlos mediante contadores Redis:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )

Preguntas sobre la API REST de comportamiento

52. Explica REST a una persona sin conocimientos técnicos.

Piensa en una API REST como en un camarero en un restaurante. Tú (el cliente) no puedes entrar directamente en la cocina. En su lugar, le dices al camarero lo que quieres del menú y él te lo trae. El menú es como la documentación de la API, en el que se enumeran los platos que puedes pedir. El camarero sigue unas reglas específicas: tú pides algo (GET), pides algo nuevo (POST) o devuelves algo (DELETE). Si en la cocina se ha acabado algo, el camarero te lo dice (404 Not Found) para que no esperes eternamente.

Esta analogía funciona sorprendentemente bien en las reuniones con las partes interesadas.

53. Describe una ocasión en la que optimizaste una API.

Utiliza el método STAR:

• Situación: «Tu API de búsqueda tenía tiempos de respuesta de 3 segundos durante los picos de tráfico».
• Tarea: «Necesitaba reducir la latencia sin realizar cambios importantes en la arquitectura».
• Acción: He añadido el almacenamiento en caché Redis para consultas frecuentes, he implementado la paginación basada en cursores y he añadido índices de base de datos.
• Resultado: El tiempo de respuesta se redujo a 200 ms y gestionamos cinco veces más tráfico.

54. ¿Cómo comunicáis los cambios importantes a los usuarios de la API?

1. Anuncia con antelación: Avisa con al menos 6-12 meses de antelación en caso de cambios importantes.

2. Utiliza el encabezado Sunset: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Proporcionar guías de migración: Documenta exactamente qué cambia y cómo adaptarse.

4. Ejecuta ambas versiones: Mantén la versión antigua en funcionamiento durante la transición.

5. Uso del monitor: Programa un seguimiento de los clientes que aún utilizan la versión antigua.

55. ¿Qué documentación creas para las API?

La documentación esencial incluye:

• Especificación OpenAPI/Swagger: Contrato legible por máquina
• Guía de inicio: Primera llamada a la API en menos de 5 minutos
• Guía de autenticación: Cómo obtener y utilizar las credenciales
• Referencia de error: Todos los códigos de error posibles y cómo gestionarlos
• Registro de cambios: Qué ha cambiado en cada versión
• Documentación sobre límites de velocidad: Límites por nivel y cómo gestionar los 429

56. ¿Cuándo NO se debe utilizar REST?

REST no siempre es la opción adecuada. Saber cuándo utilizar alternativas a demuestra madurez arquitectónica. He visto equipos forzar el uso de REST en casos en los que crea más problemas de los que resuelve.

Referencia rápida de la API REST

Utiliza esta sección como referencia rápida cuando necesites verificar las propiedades de los métodos HTTP, los códigos de estado o los patrones comunes durante la preparación de una entrevista o el desarrollo en el mundo real.

Comparación de métodos HTTP

Esta tabla resume las propiedades clave de cada método HTTP, lo quete ayudará aelegir el más adecuado para tu caso de uso.

Referencia de códigos de estado

A continuación se muestran los códigos de estado HTTP más utilizados, organizados por categoría. Céntrate en comprender cuándo utilizar cada uno, en lugar de memorizar todas las especificaciones.

2xx Éxito

• 200 OK: GET, PUT, PATCH correctos
• 201 Creado: POST correcto (incluye el encabezado Location)
• 204 Sin contenido: Eliminación correcta

Errores 4xx del cliente

• 400 Solicitud incorrecta: Sintaxis mal formada
• 401 No autorizado: Se requiere autenticación
• 403 Prohibido: Autenticado pero no autorizado
• 404 No encontrado: El recurso no existe.
• 409 Conflicto: Conflicto estatal
• 422 Entidad no procesable: Error de validación
• 429 Demasiadas solicitudes: Velocidad limitada

Errores del servidor 5xx

• Error interno del servidor 500: Fallo genérico del servidor
• 502 Puerta de enlace incorrecta: Error del servidor ascendente
• 503 Servicio no disponible: Sobrecargado temporalmente

Errores comunes que debes evitar

Incluso los programadores experimentados caen en estas trampas. Ten cuidado con estos errores comunes al diseñar o implementar API REST:

• Uso de verbos en las URL (por ejemplo, /getUsers en lugar de /users)

• Devolver 200 OK para estados de error, lo que interrumpe el manejo de errores del lado del cliente

• Confusión entre 401 y 403 (Autenticación frente a Autorización)

• URL con anidamiento excesivo más allá de dos niveles

• Almacenamiento de tokens en localStorage (crea vulnerabilidades XSS)

• Ignorar la idempotencia en las solicitudes POST

• Devolución de mensajes de error genéricos sin detalles útiles

Conclusión

Reconozco que memorizar definiciones no garantiza que apruebes todas las entrevistas técnicas. La realidad es que la ingeniería en el mundo real a menudo requiere romper las reglas «estrictas» que acabamos de comentar, y a los entrevistadores les importa más tu razonamiento que tu capacidad para recitar las especificaciones RFC. Para puestos altamente especializados, un profundo conocimiento del ámbito o una experiencia específica en el marco pueden seguir siendo el factor decisivo.

Pero dominar estos fundamentos de REST es importante incluso si no te encuentras con estas preguntas concretas. Sirve como modelo para comprender cómo funciona la web moderna. Cuando se te pide que diseñes un nuevo sistema o que solucione un fallo en la producción, comprender la diferencia entre un 401 y un 403 (como he explicado anteriormente) te permite resolver los problemas con mayor rapidez. Comprenderás exactamente por qué estandarizar tus interacciones API, y no solo escribir código que funcione, es el sello distintivo de un ingeniero sénior.

Si deseas profundizar en la creación de estos sistemas, consulta nuestra curso Introducción a las API en Python .