春季mvc和泽西岛之间的区别

Question

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.

Answer 1

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.

Answer 2

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.