Is there any trade off between using Spring mvc and Jersey Rest servlet container ? Jersey follows Jax RS standard. When I learn Spring mvc, more or less looks the same. In some applications I found people use jersey spring servlet. If spring (dispatcher servlet with handler mapping) can do all the work, then what is the need of Jersey here ? Thanks in advance.
Jersey is an alternative to Spring RESTFul applications created with @RestController . Spring is a popular Java application framework for creating enterprise applications. Spring Boot is the next step in evolution of Spring framework.
Spring Boot is considered a module of the Spring framework for packaging the Spring-based application with sensible defaults. Spring MVC is considered to be the model view controller-based web framework under the Spring framework. For building a Spring-powered framework, default configurations are provided by it.
Both Jersey and RESTEasy provide their own implementation. The difference is that Jersey additionally provides something called Chunked Output. It allows the server to send back to the client a response in parts (chunks).
JAX-RS is an specification (just a definition) and Jersey is a JAX-RS implementation. Jersey framework is more than the JAX-RS Reference Implementation. Jersey provides its own API that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development.
Spring MVC is a full Web frontend framework including support for HTML and other templating, plus other features, in addition to the JSON/XML REST features provided by Jersey.
Spring MVC was around first and has its own way of doing things. JAX-RS was defined as a standard for annotation-based REST handlers, and Jersey is an implementation of that standard. (It's very similar to @Autowired
and CDI.)
I personally prefer Spring MVC because I build on a Spring stack and can reuse code between my JSON and HTML handlers, but components intended to be deployed as one part of a customer's own system might be more flexible if using JAX-RS.
Personally I think it's just a matter of preference and what perspective you are looking at it from. I would go on to say that when making this consideration, when building different tiers, you can say that there is an extra "REST layer", on top of the other business, persistence, etc. layers. Just like persistence implementations can be swapped out, so can REST implementations.
That being said, though the endpoint/controller/resource classes look similar in implementation, other features (of the REST layer) are implemented completely different. Looking at it from a Spring perspective, I think those comfortable with Spring would choose to keep MVC as the REST implementation, for it's familiarity
Looking at it from a Jersey perspective, this is where I think most of the integration decision comes in; choosing how to implement the layers below the REST layer. For that Spring would be a viable choice, as it has a rich eco system. But being a Jersey user, the Jersey framework (for a REST implementation) seems a lot more intuitive, but that is completely bias. To use Spring and Jersey together, you can have a look at Combining Spring project and Jersey
As far as Jersey being a JAX-RS implementation, I don't see it being a deciding factor in choosing the REST implementation, when looking at it from a Spring perspective. I really don't see it being much of a factor at all. In a Java EE environment, sure you can swap out implementations with little hassle, but when Spring integration is involved, it's not that easy, as there are integration modules and configurations involved in integrating each different JAX-RS implementations with Spring.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With