Las preguntas sobre API REST evalúan si puedes diseñar una interfaz que otras personas usarán sin sorpresas. A continuación tienes 20 preguntas con respuestas, desde lo básico hasta los detalles de diseño que surgen en entrevistas de backend y full-stack. Para las reglas de los métodos HTTP, seguimos las definiciones de la RFC 9110.
Fundamentos
1. ¿Qué es REST?
REST es un estilo arquitectónico para sistemas en red, construido en torno a recursos identificados por URLs, manipulados con un conjunto reducido de operaciones estándar y descritos mediante representaciones como JSON. Una API REST es stateless (sin estado): cada petición lleva lo que el servidor necesita para procesarla, de modo que cualquier servidor puede atender cualquier petición.
2. ¿Qué hace que una API sea "RESTful" en la práctica?
- Sustantivos para los recursos en las URLs, como /orders/42, no verbos como /getOrder
- Métodos HTTP estándar para las acciones
- Códigos de estado significativos
- Peticiones sin estado
- Representaciones y formatos de error consistentes
En las entrevistas, menciona que pocas APIs reales cumplen todas las restricciones de REST y que tu objetivo es un comportamiento predecible.
3. ¿Para qué se usan los principales métodos HTTP?
| Método | Uso | Seguro | Idempotente |
|---|---|---|---|
| GET | Leer un recurso | Sí | Sí |
| POST | Crear un recurso o disparar una acción | No | No |
| PUT | Reemplazar un recurso | No | Sí |
| PATCH | Actualizar parcialmente un recurso | No | No garantizado |
| DELETE | Eliminar un recurso | No | Sí |
"Seguro" significa que la petición no modifica el estado del servidor. "Idempotente" significa que enviarla varias veces tiene el mismo efecto que enviarla una sola vez.
4. ¿Qué significa idempotente y por qué importa?
Si una petición se repite, el estado final es el mismo que tras una sola petición. Importa porque las redes fallan. Si un cliente agota el tiempo de espera en un PUT, puede reintentarlo sin miedo. Un POST que crea un pedido podría crear dos, así que las APIs suelen aceptar una clave de idempotencia: el cliente envía una clave única y el servidor devuelve el resultado almacenado si vuelve a ver esa clave.
5. ¿PUT o PATCH?
PUT reemplaza todo el recurso con el cuerpo que envías, y los campos que omites se borran o se restablecen. PATCH modifica solo los campos que envías. Usa PATCH para actualizaciones pequeñas y PUT cuando el cliente tiene la representación completa.
Códigos de estado y errores
6. ¿Qué códigos de estado usas y cuándo?
| Código | Uso |
|---|---|
| 200 | Éxito con un cuerpo |
| 201 | Creado, con una cabecera Location para el nuevo recurso |
| 204 | Éxito sin cuerpo, como un borrado |
| 400 | La petición está mal formada o es inválida |
| 401 | No autenticado |
| 403 | Autenticado pero sin permiso |
| 404 | Recurso no encontrado |
| 409 | Conflicto con el estado actual, como un duplicado |
| 422 | Bien formada pero no supera la validación |
| 429 | Demasiadas peticiones |
| 500 | Error del servidor |
| 503 | Servicio no disponible |
Una pregunta de seguimiento frecuente es la diferencia entre 401 y 403. 401 significa "no sé quién eres", y 403 significa "sé quién eres, y no puedes hacer esto".
7. ¿Cómo debería devolver errores una API?
Usa el código de estado correcto y un cuerpo consistente. Un buen cuerpo de error tiene un código estable legible por máquina, un mensaje para personas y, en los errores de validación, qué campos fallaron. No filtres trazas de pila ni detalles internos a los clientes.
8. ¿Cómo gestionas la validación?
Valida en el servidor aunque el cliente también valide. Devuelve todos los problemas a la vez cuando puedas, para que el usuario no los corrija de uno en uno, y usa 400 o 422 de forma consistente.
Diseño
9. ¿Cómo diseñas URLs para relaciones?
Anida cuando el recurso hijo solo tiene sentido bajo el padre, como /users/7/orders. Mantén el anidamiento poco profundo. Más allá de uno o dos niveles, expón el hijo directamente, como /orders/42, y filtra con parámetros de consulta, como /orders?userId=7.
10. ¿Cómo paginas una lista?
| Método | Cómo funciona | Compromiso |
|---|---|---|
| Offset y límite | ?offset=40&limit=20 | Sencillo, pero lento en tablas grandes y puede saltarse o repetir elementos cuando cambian los datos |
| Cursor | ?after=<token>&limit=20 | Estable y rápido, pero no puedes saltar a la página 50 |
| Número de página | ?page=3 | Fácil para las interfaces, con los mismos problemas que el offset |
La paginación por cursor suele ser la respuesta para datos grandes o que cambian rápido. Devuelve el siguiente cursor y una pista sobre si existen más resultados.
11. ¿Cómo filtras y ordenas?
Usa parámetros de consulta, como ?status=open&sort=-created_at. Incluye en una lista blanca los campos que permites, para evitar exponer columnas sin índice o sensibles y mantener las consultas rápidas.
12. ¿Cómo versionas una API?
| Enfoque | Ejemplo | Nota |
|---|---|---|
| En la URL | /v2/orders | Sencillo y visible |
| En una cabecera | Accept: application/vnd.example.v2+json | URLs más limpias, más difícil de probar en un navegador |
| Parámetro de consulta | ?version=2 | Fácil, pero fácil de olvidar |
Elijas lo que elijas, evita cambios que rompan la compatibilidad dentro de una versión. Añadir campos suele ser seguro, y eliminar o renombrar campos no lo es.
13. ¿Qué es HATEOAS?
Las respuestas incluyen enlaces a acciones relacionadas, para que un cliente pueda descubrir qué puede hacer a continuación en lugar de codificar las URLs a mano. Forma parte de la definición de REST, pero pocas APIs lo implementan por completo. Di que lo conoces y que la mayoría de los equipos usan documentación y una descripción OpenAPI en su lugar.
Seguridad y rendimiento
14. ¿Cómo autenticas una API?
Las opciones habituales son claves de API para un uso sencillo de servidor a servidor, tokens de portador como los JSON Web Tokens, y OAuth 2.0 cuando un usuario concede a una aplicación acceso a sus datos. Usa siempre HTTPS. Mantén los secretos fuera de las URLs, ya que las URLs acaban en los registros.
15. ¿Cuál es la diferencia entre autenticación y autorización?
La autenticación es demostrar quién eres. La autorización es decidir qué tienes permitido hacer. Fallan de forma distinta: un token ausente o inválido es 401, y un token válido sin permiso es 403.
16. ¿Cómo proteges una API del abuso?
Limitación de tasa por clave o por IP, límites de tamaño de las peticiones, validación de la entrada, tiempos de espera y monitorización de tráfico inusual. Devuelve 429 con una cabecera Retry-After para que los clientes sepan cuándo volver a intentarlo.
17. ¿Cómo funciona el almacenamiento en caché HTTP para las APIs?
Las respuestas pueden llevar cabeceras Cache-Control que indican cuánto tiempo se puede reutilizar una respuesta. Un ETag identifica una versión de la respuesta. El cliente lo devuelve en If-None-Match, y el servidor responde 304 Not Modified sin cuerpo si nada ha cambiado. Ahorra ancho de banda y carga.
18. ¿Qué es CORS?
Los navegadores bloquean que una página web lea respuestas de un origen distinto a menos que el servidor lo permita. El servidor envía cabeceras como Access-Control-Allow-Origin para indicar qué orígenes pueden leer sus respuestas. Lo aplica el navegador, no el servidor, así que no protege una API de clientes que no sean navegadores.
Práctica
19. ¿REST o GraphQL o gRPC?
| Bueno para | Coste | |
|---|---|---|
| REST | APIs públicas sencillas, cacheables y ampliamente entendidas | Exceso de datos y muchas idas y vueltas para pantallas complejas |
| GraphQL | Clientes que necesitan elegir exactamente los campos y combinar datos en una sola petición | Más complejidad en el servidor y almacenamiento en caché más difícil |
| gRPC | Llamadas internas rápidas de servicio a servicio con contratos estrictos | Menos amigable para navegadores y uso público |
La mejor respuesta nombra una situación, no un ganador.
20. ¿Cómo documentas y pruebas una API?
Descríbela con una especificación OpenAPI, que puede generar documentación y código de cliente. Prueba en tres niveles: pruebas unitarias para la lógica, pruebas de integración contra una base de datos real y pruebas de contrato para detectar cambios que rompan la compatibilidad. Prueba también los casos de fallo, como entradas inválidas y tokens caducados.
Cómo prepararte
- Sé capaz de diseñar una API pequeña en una pizarra, como una lista de tareas o un sistema de pedidos, con URLs, métodos, códigos de estado y una respuesta de error.
- Domina la idempotencia y la paginación a fondo. Son los temas que más salen.
- Prepara una historia sobre una API que construiste o usaste, y un error que evitarías la próxima vez.
Para practicar temas relacionados, consulta nuestras guías de preguntas de entrevista de Spring Boot, preguntas de entrevista de Node.js, preguntas de entrevista de diseño de sistemas y preguntas de entrevista de redes informáticas.
Practica en voz alta y con tus propias palabras. Una transcripción posterior muestra dónde divagaste o te saltaste el punto. Sigue las normas del empleador sobre herramientas de IA en cualquier entrevista o evaluación en vivo.
Practica tus respuestas con YesToTheOffer
Ensaya en voz alta, obtén respuestas creadas a partir de tu propio currículum y revisa tu transcripción después. 30 minutos gratis, sin suscripción.
