The ink is still drying on Jakarta EE 9 / 9.1 and the Jakarta RESTful Web Services 3.0 specs, but the REST community isn’t slowing down. While vendors and developers are rapidly adopting EE 9, the Jakarta REST (aka JAX-RS) community is actively preparing for future releases.
DISCLAIMER: Everything in this post is planned as of the time of writing, but is subject to change without notice.
Our plans for a standalone 3.1 release have been approved. What does standalone mean? Just that it won’t be included in a larger Jakarta EE umbrella release. That might hinder adoption for some vendors who are more concerned about only implementing full profiles, like the Jakarta EE Platform or Web Profile. Still, I expect many vendors will offer the 3.1 release – either as a standalone product or feature, or as an extension of their EE 9/9.1 implementation. Other vendors may wait for an EE 10 release, which should include all of the new features from 3.1 as well as newer features from a proposed Jakarta REST 4.0 release.
Ok, so what should we expect in Jakarta REST 3.1? Here are the proposed new features:
- Java SE Bootstrap API
- Support for sending and receiving multipart/form-data payloads
- Better alignment with JSON-B
- Automatic loading of provider extensions
- Deprecation of @Context in preparation for better alignment with CDI
Java SE Bootstrap API
The idea here is to make it easier to build and deploy a RESTful service without the need of a full EE container/server/etc. Servers like Open Liberty, WebSphere Application Server, and Wildfly are great, but wouldn’t it be nice to be able to launch a RESTful service in Java SE sometimes? The use cases could include setting up a “mock” server to test your client code against, or even a production ready service that might not need all of the bells and whistles that a full server environment might provide.
See the Jakarta REST examples for how to code it.
Support for Multipart
The multipart/form-data content type has been around for a long time – and is often used to transfer multiple disparate data types from one point to another. For example, you might apply for a job on a site and send your name and address in an HTML form that also includes your resume (DOC or PDF file) and your picture (PNG, JPG, etc.). Under the hood, this is sent as a multipart request.
Until now, the Jakarta REST spec has not defined how to accept incoming multipart content or how to send it. Vendors have implemented their own approach at providing APIs for sending and receiving multipart content, but the 3.1 spec makes this portable and provides a way for all vendor implementations to provide the same level of functionality.
There are some examples for how to code it here.
JSON-B Alignment
A few years back, Adam Bien wrote an excellent blog post on how to configure JSON-B in a Jakarta REST application. The only trouble is that at that time, the approach only worked with Eclipse Jersey. Since then other implementations (including Open Liberty via Apache CXF) also enabled this functionality, but it will become a standard in 3.1, enabling more portable usage of JSON-B configuration.
What does JSON-B configuration really mean? Let’s say that you want your RESTful service to always use a specific naming strategy when converting from Java field names to JSON. This is something you would configure in a JsonbConfig object. But in order to ensure that your Jakarta REST app uses that configuration, you would need to register a ContextResolver<JsonbConfig> provider that returns your customized config object.
Provider Extensions
Most Jakarta REST applications are self-contained artifacts – usually WARs or fat/thin JARs, etc. But there are times, particularly in cloud environments, where you may want to add extensions to the application for additional qualities of service. For example, maybe you’d like to add some monitoring extensions to collect performance metrics, diagnostic tracing, or audit logging. Using the new provider extension support in Jakarta REST 3.1, these types of extensions could be applied outside of the application packaging. This will allow vendors and other third-party library developers to build extension JARs that can be added to the classpath of the application for quick and easy activation. This is all handled using the ServiceLoader mechanism.
Deprecation of @Context for better CDI Integration
Historically, JAX-RS and CDI were developed around the same time by two different groups. As such both groups built their own dependency injection mechanism. JAX-RS’s dependency injection mechanism is specific to RESTful services and injects a limited number of object types that are annotated with @Context. CDI is much more flexible and is intended to be the de facto injection mechanism for all of Jakarta EE – it uses the more common @Inject annotation. In 3.1, the Jakarta REST community made the decision to replace their component-specific injection mechanism with CDI. In a future release (presumably 4.0), the @Context annotation will be removed.
This should pave the way for vendors to reduce install footprint by using a single dependency injection mechanism. It also will allow more flexibility beyond just injection in RESTful applications. If you’re not familiar with CDI, you can learn more about it in the Open Liberty CDI guide.
The future of REST in Java certainly looks bright. What new features would you like to see? Please feel free to leave a comment with your ideas here or open an issue at the Jakarta REST GitHub site. Until then, stay RESTful! 😉
This post was originally published on May 3, 2021 at: https://andymc12.net/2021/05/03/whats-coming-in-jakarta-rest-3-1/
Top comments (0)