En el universo en expansión de Quarkus, a veces es necesario detener la nave, mirar el mapa y recalibrar coordenadas. Sobre todo cuando una decisión de nomenclatura puede alterar la brújula de muchos desarrolladores.

🚨 Diferencias entre Quarkus REST, RESTEasy Reactive y Classic

Desde Quarkus 3.9, la extensión quarkus-resteasy-reactive fue renombrada a quarkus-rest. No hubo cambios técnicos relevantes, solo un cambio de nombre para evitar confusiones.

La funcionalidad sigue siendo la misma: una única implementación moderna, eficiente y basada en Vert.x, capaz de manejar tanto código imperativo como reactivo.

El nuevo nombre quarkus-rest ya no refleja la implementación interna, sino que se alinea con el estilo arquitectónico REST, compatible tanto con programación imperativa como reactiva.

🔍 ¿Por qué era confuso?

El problema estaba en el nombre. Muchos desarrolladores creían que quarkus-resteasy-reactive solo servía para código reactivo explícito, con tipos como Uni o Multi. Y eso no era cierto. Desde su origen soportó ambos estilos:

• Programación imperativa tradicional (JAX-RS)
• Programación reactiva con Mutiny

La confusión crecía porque quarkus-resteasy seguía existiendo como opción imperativa pura, y por eso muchos asumían que, para cubrir ambos estilos, debían sumar también quarkus-resteasy-reactive. Sin embargo, eso era innecesario —e incluso desaconsejado—, ya que quarkus-resteasy-reactive (hoy quarkus-rest) estaba diseñado para manejar ambos enfoques de forma unificada, y su uso conjunto con quarkus-resteasy podía generar conflictos o redundancias.

🧭 Nombres desde Quarkus 3.9

💡 ¿Qué estilo de código puedo usar con quarkus-rest?

Ambos. Y el framework se adapta automáticamente.

Imperativo:

@GET
@Path("/saludo")
public String hola() {
    return "Hola imperativo";
}

@GET
@Path("/saludo")
public String hola() {
    return "Hola imperativo";
}

Reactivo con Mutiny:

@GET
@Path("/reactivo")
public Uni<String> holaAsync() {
    return Uni.createFrom().item("Hola reactivo");
}

@GET
@Path("/reactivo")
public Uni<String> holaAsync() {
    return Uni.createFrom().item("Hola reactivo");
}

Ambos funcionan sobre la misma extensión (quarkus-rest) y Quarkus se encarga del cambio de hilos cuando detecta operaciones bloqueantes.

🔄 ¿Qué tengo que hacer si usaba quarkus-resteasy-reactive?

En la mayoría de los casos, migrar es tan simple como reemplazar la extensión quarkus-resteasy-reactive por quarkus-rest.

Si usas:

quarkus update

quarkus update

el cambio suele aplicarse automáticamente, junto con otros ajustes menores en dependencias. Sin embargo, recuerda que en proyectos reales —especialmente en contextos empresariales— siempre es recomendable validar que no haya efectos colaterales por cambios acumulados entre versiones.

Para más detalles técnicos sobre este cambio y otros ajustes introducidos en la versión 3.9, podés consultar la Guía de migración oficial de Quarkus 3.9 (en inglés), mantenida por el equipo del proyecto. Allí se documentan los cambios de nombre, recomendaciones y consideraciones adicionales para migraciones seguras.

Si estás trabajando con Red Hat Build of Quarkus, también puedes consultar las notas específicas para las versiones posteriores a Quarkus 3.9:

• RHBQ 3.15 release notes (en inglés)
• RHBQ 3.20 release notes (en inglés)

Estas páginas ofrecen información detallada sobre compatibilidad, cambios clave y lineamientos para entornos empresariales soportados por Red Hat.

📌 Conclusión

quarkus-rest no es una nueva tecnología.
Es simplemente el nuevo nombre de quarkus-resteasy-reactive, una extensión que ya soportaba ambos estilos (imperativo y reactivo) desde hace años.

El cambio de nombre elimina una ambigüedad común y deja claro que esta es la implementación moderna y recomendada para construir APIs REST en Quarkus.

¿Te sirvió esta aclaración? Compartila con tu equipo o seguí explorando la categoría Curiosidades del Quarkiverso 🚀