Spring Boot y APIs REST: errores que te descartan

Dominar Spring Boot y APIs REST no basta: las empresas descartan candidatos backend por errores concretos que se repiten en pruebas técnicas y entrevistas. Si ya sabes levantar un controlador y conectar una base de datos, el siguiente filtro es demostrar criterio de producción. Aquí tienes los fallos más penalizados y cómo evitarlos con resultados medibles.

Errores en el diseño de APIs REST que delatan falta de experiencia

El primer filtro técnico suele ser un ejercicio de diseño. Los reclutadores detectan rápido si solo has consumido tutoriales. Estos son los fallos más comunes:

• Verbos en las rutas: usar /getUsuarios o /crearPedido en lugar de apoyarte en los métodos HTTP (GET, POST, PUT, PATCH, DELETE).
• Ignorar los códigos de estado: devolver 200 para todo, incluso cuando hay errores. Un 201 al crear, 204 al borrar y 404 cuando no existe el recurso son expectativas básicas.
• Anidar recursos sin criterio: rutas como /api/v1/empresas/1/departamentos/2/empleados/3/tareas dificultan el mantenimiento y el versionado.
• No versionar: cambiar el contrato sin /v1/ rompe a los clientes que ya consumen la API.
• Paginación ausente: devolver listados completos sin page, size ni sort es un problema de rendimiento garantizado.

Cómo evitarlo: antes de escribir código, define el contrato. Documenta con OpenAPI y valida que cada endpoint tenga propósito único. Si quieres reforzar estas bases con ejemplos guiados, en los cursos de Spring Frameworks de TecGurus trabajan diseño de controladores, validación y manejo de errores con proyectos reales.

Fallos en la capa de servicio y persistencia con Spring Boot

Aquí es donde se separan los perfiles junior de los que las empresas quieren retener. Los errores típicos:

1. Lógica de negocio en el controlador

Meter validaciones, cálculos y acceso a datos en el @RestController hace el código intesteable. La regla es simple: el controlador orquesta, el servicio decide, el repositorio persiste.

2. Inyección de dependencias mal usada

Usar @Autowired en campos en lugar de inyección por constructor impide la inmutabilidad y complica las pruebas unitarias. Las empresas valoran constructores explícitos y beans bien delimitados.

3. Transacciones mal gestionadas

Anotar @Transactional en el controlador o en métodos que no lo necesitan genera bloqueos y problemas de consistencia. Debe ir en la capa de servicio, con el alcance mínimo posible.

4. Consultas N+1 con JPA

Cargar entidades perezosas dentro de un bucle dispara decenas de consultas. Se corrige con JOIN FETCH, @EntityGraph o proyecciones DTO. Es una de las preguntas más frecuentes en entrevistas técnicas.

5. Exponer entidades directamente

Devolver la entidad JPA en el JSON acopla la base de datos al contrato público y filtra campos sensibles. Usa DTOs y mapeadores.

Qué miran las empresas en las pruebas técnicas de backend

Más allá de que el endpoint funcione, los evaluadores revisan señales de madurez:

1. Manejo global de excepciones: un @ControllerAdvice con respuestas de error consistentes.
2. Validación de entrada: uso de @Valid y Bean Validation en los DTOs de request.
3. Pruebas: al menos pruebas de integración con MockMvc o Testcontainers, no solo unitarias triviales.
4. Seguridad: Spring Security configurado con JWT u OAuth2, roles y protección de endpoints.
5. Observabilidad: logs estructurados, Actuator y métricas básicas.
6. Perfilado: separar configuración por entornos con application-{profile}.yml.

Si tu portafolio no cubre estos puntos, conviene revisar qué conceptos se están pidiendo en el mercado. Puedes contrastar ofertas reales en la bolsa de empleo de TecGurus y detectar patrones en los requisitos: casi todas repiten Spring Boot, JPA, seguridad y pruebas.

Errores de rendimiento y escalabilidad que cuestan entrevistas

Las empresas que operan APIs con tráfico real buscan candidatos que anticipen problemas. Estos descuidos son penalizados:

• No cachear: ignorar @Cacheable o cabeceras HTTP de caché en lecturas frecuentes.
• Bloquear hilos: usar llamadas síncronas donde WebClient o programación reactiva aportan valor.
• Pool de conexiones por defecto: no ajustar HikariCP según la carga esperada.
• Serialización descuidada: devolver objetos enormes en lugar de proyecciones ligeras.
• Falta de idempotencia: en POST críticos (pagos, reservas) sin claves de idempotencia.

Evitarlos exige entender el ciclo de vida de la petición y medir. Herramientas como JMeter, Gatling o el propio Actuator ayudan a justificar decisiones con datos, algo que impresiona en una entrevista técnica.

Cómo prepararte para destacar en procesos backend

El patrón que buscan las empresas combina fundamentos sólidos, criterio de producción y capacidad de comunicar decisiones. Un plan realista:

1. Construye una API REST completa con Spring Boot: autenticación, roles, validación, paginación y pruebas.
2. Documenta con OpenAPI y publica el repositorio con un README claro.
3. Mide rendimiento y explica en una nota técnica qué optimizaste y por qué.
4. Revisa ofertas reales para calibrar el nivel exigido y ajusta tu portafolio.
5. Refuerza los puntos débiles con formación práctica, no solo teoría.

Para cerrar la brecha entre saber Spring Boot y demostrarlo en producción, conviene repasar los fundamentos que más se preguntan. En esta guía de conceptos clave de backend con Java y Spring Boot encontrarás un repaso útil para preparar entrevistas y detectar lagunas antes de que lo haga el entrevistador.

La diferencia entre un candidato descartado y uno contratado rara vez es saber más frameworks: es evitar los errores que todos cometen y demostrar que entiendes por qué importan.