Apache CXF builds REST-style HTTP services through its JAX-RS frontend. You define resource classes and methods with JAX-RS annotations; CXF connects those resources to an HTTP endpoint, selects a method from the request path and HTTP verb, and uses providers to read and write representations such as JSON or XML. For new CXF REST work, JAX-RS is the practical starting point; older CXF documentation also describes approaches that are no longer current.
What CXF provides for REST
Apache CXF is an open-source services framework with frontends including JAX-WS and JAX-RS. Its REST-oriented path is JAX-RS, the Java API for creating services in the REST architectural style. CXF documentation describes support for JAX-RS 1.1, 2.0, and 2.1; the exact APIs and integrations available to a project depend on its CXF branch and runtime.
As an Amazon Associate I earn from qualifying purchases.
In a typical application, JAX-RS annotations describe the resource and its operations, while CXF handles the framework integration: endpoint setup, request dispatch, providers, filters, and client options. CXF can be configured in multiple deployment styles, including servlet-based deployments. It also documents service descriptions, validation, security-related features, asynchronous calls, and failover facilities.
How CXF routes a REST request
A request reaches a CXF endpoint through the HTTP server or servlet mapping. The servlet URL pattern and the JAX-RS server address establish the portion of the URL handled by that endpoint. CXF then matches the remaining path against resource-level and method-level @Path annotations, and selects an operation whose HTTP-method annotation matches the request verb.
For example, a resource might be declared with @Path("/orders"), with a method annotated @GET and @Path("/{id}"). That method is a candidate for a GET request to the resource’s /orders/{id} path, provided the servlet mapping and JAX-RS server address route the request to that application. A correctly annotated resource will not be reachable if the endpoint’s address or servlet mapping does not expose it.
- HTTP entry point: the configured server or servlet accepts the request.
- Endpoint base: the CXF JAX-RS server address and, where applicable, servlet URL pattern determine the endpoint prefix.
- Resource matching: CXF matches path annotations and the HTTP method to a resource operation.
- Entity handling: providers read the incoming body and write the response representation.
When a route fails, check the composed URL first, then confirm the resource and method annotations match the path and verb. Also verify that the required providers are registered for the media types used by the request and response.
Choosing how to build a CXF REST service
JAX-RS resources
Use JAX-RS resource classes for the ordinary REST case: resources expose paths and operations with annotations, while providers and CXF configuration supply the surrounding runtime behavior. This is the maintained REST-oriented route described by CXF’s documentation and gives the application access to standard JAX-RS concepts.
JAX-WS Provider or Dispatch
CXF’s historical REST overview also describes using JAX-WS Provider or Dispatch. These are alternatives for particular service designs, not the default choice for a new JAX-RS-style REST API. Check the documentation for the specific CXF branch before adopting a legacy arrangement.
Rank #3
HTTP Binding
The same historical overview lists HTTP Binding, but CXF removed it in version 2.6.0. Do not choose it for a new project; if maintaining an older service that uses it, verify the compatibility and migration implications for that service’s CXF branch.
Calling a CXF REST service from Java
CXF offers both the standard JAX-RS client API and CXF-specific client facilities. Choose based on whether portability through standard APIs or CXF-specific configuration and conveniences matter more to the client application.
| Client approach | Best fit | What to account for |
|---|---|---|
| JAX-RS client API | Applications that prefer the standard JAX-RS client model. | Confirm that the CXF branch and runtime provide the JAX-RS API level and provider configuration the client needs. |
| CXF WebClient | Applications that want CXF’s own HTTP client facilities. | It is CXF-specific, so client code is more closely tied to CXF. |
| CXF proxy-style client | Applications that prefer an interface-oriented way to invoke a service. | Review the proxy configuration and its relationship to the service’s resource contract. |
These approaches are not different server routing systems: they are alternative ways for Java code to issue requests to a REST endpoint. CXF also documents synchronous and asynchronous invocation, along with reactive styles for documented client and transport combinations, including JAX-RS 2.1 RxInvoker support. Check the chosen combination rather than assuming every invocation style works with every transport or branch.
Free tools Windows power users keep installed
One-click scans. No signup required.
Representations, providers, and service descriptions
JAX-RS uses message-body readers and writers, commonly called providers, to translate between HTTP entities and Java values. CXF documents support for JSON and XML representations as well as data-binding options including JAXB, Aegis, and SDO. Which format is available in an application depends on its registered providers and configuration; an annotation indicating a media type does not by itself supply a missing provider.
CXF also documents WADL service descriptions and Swagger documentation. These can help describe or expose an API contract, but their availability and exact behavior should be checked against the selected CXF branch. Treat generated documentation as a contract aid, and keep it aligned with the paths, media types, and operations the deployed service actually exposes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Cross-cutting behavior and deployment
Request and response filters and CXF interceptors let an application add processing around resource methods. CXF also documents bean validation, HTTPS, authentication and authorization features, OAuth2-related capabilities, and failover. These are building blocks rather than a guarantee that a service is secure or production-ready automatically: applications still need to configure the appropriate controls and verify them in the chosen deployment.
- Validation: use the documented bean-validation integration where inputs need constraint checks.
- Request and response processing: use JAX-RS filters or CXF interceptors for cross-cutting behavior suited to their respective layers.
- Transport and access controls: configure HTTPS and the authentication or authorization approach required by the service; confirm any OAuth2-related integration against the target branch.
- Operations: decide how the endpoint will be deployed and monitored, and whether documented failover features fit the service’s runtime and availability requirements.
Which CXF version should you choose?
Choose a maintained branch only after matching its compatibility notes to your JDK, Jakarta EE namespace level, servlet container, and other application dependencies. Do not infer those requirements from a version number alone: the available evidence here does not establish a full compatibility matrix for the listed branches.
The Apache CXF project index announced the following patch releases on August 5, 2026:
| Release | Issues reported fixed in the announcement | Security note |
|---|---|---|
| CXF 4.2.3 | Over 10 JIRA issues | The announcement says the releases contain fixes for multiple CVE issues. |
| CXF 4.1.8 | 6 JIRA issues | The announcement says the releases contain fixes for multiple CVE issues. |
| CXF 3.6.12 | 4 JIRA issues | The announcement says the releases contain fixes for multiple CVE issues. |
Those figures describe the Apache project’s August 5, 2026 announcement, not a promise that these remain the newest releases. Before shipping, check the project’s release information for patches announced after that date, read the compatibility notes for the branch you plan to use, and review its security advisories.
Quick Recap
A practical decision checklist
- Start with JAX-RS for a new CXF REST API unless a specific legacy or integration requirement calls for another documented approach.
- Confirm the CXF branch, JDK, Jakarta EE namespace, and container are compatible with one another.
- Map the complete request URL from the servlet mapping and CXF server address through to the resource’s
@Pathannotations. - Choose the JAX-RS client API, WebClient, or proxy style based on portability and CXF-specific needs.
- Register and verify the providers required for the API’s JSON, XML, or other representations.
- Configure validation, filters or interceptors, HTTPS, and access controls deliberately; select asynchronous or reactive invocation only after checking the documented client and transport combination.
- Check current release and security information before production deployment.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
