Cómo explicar tus APIs REST sin parecer junior en la entrevista

Te piden que diseñes una API REST para un sistema de reservas. Empezás a hablar: "Bueno, haría un POST a /reservas y un GET para listar...". El entrevistador asiente educadamente, pero ya perdiste puntos. No porque tu respuesta sea incorrecta, sino porque no mostraste cómo pensás. La diferencia entre un candidato junior y uno senior no está en conocer todos los status codes, sino en comunicar decisiones de diseño REST como si estuvieras resolviendo un problema real con un equipo real.

La trampa clásica es creer que las entrevistas técnicas evalúan conocimiento. Evalúan criterio. Y el criterio se demuestra haciendo las preguntas correctas, explicitando supuestos y admitiendo qué no sabés. Este artículo no es una guía de REST (eso ya lo conocés). Es una técnica para verbalizar tu proceso de pensamiento backend cuando te toca diseñar APIs frente a un entrevistador.

Arrancá con contexto, no con código

El error más común: saltar directo a rutas y métodos. El entrevistador dice "diseñá una API para gestionar productos" y vos respondés:

GET /productos
POST /productos
PUT /productos/:id
DELETE /productos/:id

Técnicamente correcto. Pero acabás de demostrar que no hacés preguntas. Un backend real siempre arranca entendiendo el caso de uso. Antes de tirar un endpoint, verbalizá esto:

"Antes de definir rutas, necesito entender el flujo. ¿Esta API la consume un frontend público o un panel de admin? ¿Los productos tienen variantes, stock, imágenes? ¿Esperamos volumen alto de lecturas?"

No importa si el entrevistador te responde "asumí lo que quieras". Lo importante es que mostraste que pensás en quién usa la API y para qué. Un junior ve endpoints como CRUD genérico. Un senior ve contratos entre sistemas.

Si el entrevistador no da detalle, explicitá tus supuestos en voz alta:

"Voy a asumir que es un e-commerce básico, con productos simples (sin variantes complejas), consumido por un frontend web. Eso me permite optimizar para lecturas y mantener el modelo simple."

Acabás de demostrar tres cosas:

1. Entendés que el contexto cambia las decisiones
2. Sabés delimitar alcance (evitar over-engineering)
3. Podés justificar por qué diseñaste así

Diseñá rutas pensando en recursos, no en acciones

La segunda trampa: nombrar rutas como si fueran funciones. Esto es código junior:

POST /crearProducto
POST /actualizarStock
GET /obtenerProductosPorCategoria

REST modela recursos, no acciones. El verbo HTTP ya indica la operación. Pero acá también podés mostrar criterio mientras hablás:

"Para productos, el recurso principal es /productos. Los métodos HTTP mapean operaciones: GET para leer, POST para crear, PUT/PATCH para actualizar, DELETE para eliminar."

Hasta acá, estándar. Ahora subí el nivel:

"Si necesito filtrar por categoría, tengo dos opciones: query params como /productos?categoria=electronica, o una ruta anidada como /categorias/:id/productos. La primera es más simple y funciona si las categorías son solo filtros. La segunda tiene sentido si las categorías son un recurso propio con lógica de negocio."

Ahí mostraste que:

• Conocés la diferencia entre recursos anidados y query params
• Podés justificar cuándo usar cada uno
• No das respuestas automáticas, evaluás trade-offs

Si el entrevistador pregunta "¿y si necesitás actualizar solo el stock?", evitá el reflejo de crear /actualizarStock. En cambio:

"Tengo dos caminos. PATCH /productos/:id con { "stock": 50 } si es una actualización parcial simple. O un recurso anidado como PUT /productos/:id/stock si la operación de stock tiene validaciones complejas (control de concurrencia, reservas)."

Explicaste la decisión, no solo la solución.

Validación y errores: lo que separa a un API seria de una de tutorial

Acá es donde la mayoría se queda en la superficie. Te preguntan "¿qué validaciones hacés?" y respondés:

"Valido que los campos requeridos estén presentes y devuelvo un 400 si algo falla."

Correcto pero incompleto. Mostrá que pensás en dónde vive cada validación y cómo el cliente la consume:

"Las validaciones las pienso en tres niveles. Primero, validación de estructura: campos requeridos, tipos de datos, formato de email. Eso va en el controller antes de tocar lógica de negocio. Devuelvo 400 con un JSON que lista todos los errores, no solo el primero."

// Respuesta de validación útil
{
  "error": "Validation failed",
  "details": [
    { "field": "email", "message": "Formato inválido" },
    { "field": "precio", "message": "Debe ser mayor a 0" }
  ]
}

"Segundo nivel: validaciones de negocio. Por ejemplo, verificar que la categoría existe o que el SKU no está duplicado. Eso puede ser un 400 si es input del usuario o un 409 (Conflict) si es un problema de estado."

"Tercer nivel: errores del sistema. Si falla la base de datos o un servicio externo, devuelvo 500 o 503, pero logeo el error completo sin exponer detalles al cliente."

Acabás de demostrar que:

• Entendés la diferencia entre validación de input y lógica de negocio
• Conocés status codes más allá de 200 y 400
• Pensás en la experiencia del desarrollador frontend que consume tu API

Si querés ir más allá, mencioná casos edge:

"Si el producto no existe, devuelvo 404. Si existe pero el usuario no tiene permisos, 403. Puede parecer detalle, pero un 404 genérico para ambos casos filtra info de seguridad."

Admití lo que no sabés (pero mostrá cómo lo resolverías)

Acá está el superpoder que pocos juniors tienen: admitir incertidumbre sin sonar inseguro. El entrevistador te pregunta:

"¿Cómo manejás rate limiting en esta API?"

Si no lo hiciste antes, el instinto es inventar o quedarte mudo. Mejor:

"No implementé rate limiting en producción todavía, pero mi approach sería usar algo como Redis para trackear requests por IP o por API key en una ventana de tiempo. Devolvería 429 (Too Many Requests) con un header Retry-After. Si necesito más detalle técnico, puedo investigar bibliotecas específicas del stack."

Mostraste:

1. Entendés el concepto (no es magia negra)
2. Sabés que existen herramientas para resolverlo
3. Conocés el status code correcto
4. No pretendés saber lo que no sabés

Lo mismo con autenticación:

"Para autenticación, probablemente usaría JWT en el header Authorization: Bearer <token>. Pero si es info sensible, preguntaría si necesitamos refresh tokens, cuánto dura la sesión y si hay que manejar logout en backend (invalidar tokens). Eso cambia la arquitectura."

No dijiste "usemos JWT y listo". Mostraste que entendés que cada decisión tiene implicaciones y que hacés las preguntas correctas.

Checklist: qué decir cuando diseñás una API en una entrevista

Antes de tirar tu primera ruta, verbalizá estos puntos:

• Contexto de uso: ¿Quién consume esta API? ¿Es pública, interna, mobile, web?
• Volumen esperado: ¿Optimizo para lecturas? ¿Escrituras? ¿Hay cacheo?
• Modelo de datos: ¿Los recursos tienen relaciones? ¿Necesito endpoints anidados?
• Convenciones de naming: ¿Usamos plural? (/productos vs /producto)
• Paginación: ¿Las listas son acotadas o necesito ?page=1&limit=20?
• Versionado: ¿Va en la URL (/v1/productos), en headers, o lo dejo para después?
• Validaciones críticas: ¿Qué puede romper el sistema si no valido?

Cuando expliques validaciones:

• Dónde vive cada validación (input, negocio, sistema)
• Qué status code devuelvo (400, 404, 409, 500)
• Qué info incluyo en el error (lista de campos, mensaje genérico)

Si no sabés algo:

• Admitilo explícitamente: "No lo hice, pero investigaría X"
• Mostrá tu proceso: "Buscaría en la doc de [herramienta], o preguntaría si hay un patrón ya definido en el equipo"
• Ofrecé contexto relacionado: "No conozco GraphQL en detalle, pero entiendo que resuelve over-fetching"

Preguntas frecuentes

¿Qué hago si el entrevistador no me da contexto?

Asumí un caso de uso razonable y explicitalo en voz alta: "Voy a asumir que es un MVP con tráfico moderado, sin usuarios concurrentes altos". Si tu supuesto es incorrecto, el entrevistador te va a corregir. Eso es bueno: genera conversación.

¿Es necesario memorizar todos los status codes HTTP?

No. Con conocer 200, 201, 400, 401, 403, 404, 500 y 503 alcanza para la mayoría de diseños. Si mencionás un 409 (Conflict) o 429 (Rate Limit) en contexto correcto, sumás puntos. Pero inventar status codes o usarlos mal resta más que no mencionarlos.

¿Qué tan técnico tengo que ser al explicar validaciones?

Depende del nivel de la posición. Para roles semi-senior: mencioná dónde validás y qué devolvés. Para senior/tech lead: hablá de validación asíncrona (verificar en DB), idempotencia (reintentos seguros con Idempotency-Key), y cómo las validaciones afectan testing.