Migrating from RESTEasy Classic to RESTEasy Reactive is straightforward in most cases, however there are a few cases that require some attention. This document provides a list of issues users attempting the migration should be aware of.
The reference documentation of RESTEasy Reactive can be found here. |
Server
The server part of RESTEasy Reactive (quarkus-resteasy-reactive
and its dependencies) provide an implementation of the JAX-RS specification, but leverage Quarkus' build time processing
and the unified I/O model provided by Vert.x.
Dependencies
The following table matches the legacy RESTEasy dependencies with the new RESTEasy Reactive ones.
Legacy | RESTEasy Reactive |
---|---|
|
|
|
|
|
|
|
|
|
|
The quarkus-resteasy-mutiny does not have a corresponding dependency, as RESTEasy Reactive provides Mutiny integration out of the box.
|
Annotations
RESTEasy Reactive does not support the various custom annotation under the org.jboss.resteasy.annotations
package.
The following table matches the legacy RESTEasy annotations with the new RESTEasy Reactive ones.
Legacy | RESTEasy Reactive | Comments |
---|---|---|
|
|
This annotation is not necessary when the path part matches the method parameter name |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
JAX-RS providers
Although RESTEasy Reactive provides the same spec compliant behavior as RESTEasy Classic does, it does not include the same exact provider implementations at runtime.
The most common case where the difference in providers might result in different behavior, is the included javax.ws.rs.ext.ExceptionMapper
implementations. To see what classes are included in the application, launch the application in dev mode and navigate to http://localhost:8080/q/dev/io.quarkus.quarkus-resteasy-reactive/exception-mappers.
Multipart support
HTTP Multipart support in RESTEasy Reactive does not reuse the same types or annotations as RESTEasy Classic and thus users are encouraged to read this part of the reference documentation.
Default media types
Quarkus uses smart defaults when determining the media type of JAX-RS methods in order to simplify common use cases.
The difference between quarkus-resteasy-reactive
and quarkus-resteasy
is the use of text/plain
as the default media type instead of text/html
when the method returns a String
.
Client
The Reactive REST Client (quarkus-rest-client-reactive
and its dependencies) replace the legacy quarkus-rest-client
but leverage Quarkus' build time processing
and the unified I/O model provided by Vert.x.
Dependencies
The following table matches the legacy REST Client dependencies with the new Reactive REST Client ones.
Legacy | RESTEasy Reactive |
---|---|
|
|
|
|
|
|
|
|
Keycloak admin client
When using quarkus-rest-client
, users can use the quarkus-keycloak-admin-client
to administer the target Keycloak instance
by leveraging the rest client.
When using quarkus-rest-client-reactive
however, users must use quarkus-keycloak-admin-client-reactive
to access the same functionality
and use the reactive REST Client.
OIDC
When using quarkus-rest-client
, users can use the quarkus-oidc-client-filter
extensions to acquire and refresh access tokens from OpenID Connect and OAuth 2.0 compliant Authorization Servers.
When using quarkus-rest-client-reactive
however, users must use quarkus-oidc-client-filter-reactive
to access the same functionality.
Similarly, quarkus-oidc-token-propagation
allows user of the legacy REST to propagate the current Bearer
or Authorization Code Flow
access tokens.
When using quarkus-rest-client-reactive
however, users must use quarkus-oidc-token-propagation-reactive
to access the same functionality.