Let’s Compare: JAX-RS vs Spring for REST Endpoints
A comparison of JAX-RS and Spring MVC for creating REST endpoints. This tutorial includes a section showing how you can use them together.
amihaiemil
You did not compare apples to apples, you compared apples to pears to begin with!
You regard JAX-RS as a standalone framework, which it is not!
1) Jax-rs is a component of JavaEE, you do not even need to know whether you are using Jersey or RestEasy – it is a specification, an API, the implementation should be irrelevant. And your code snippet seems a lot more complex than it should be.
2) Spring and JavaEE (including JAX-RS) are competitors, rivals, you should never put them together in a project, it makes no sense. It only shows that you have no idea what you are doing, architecture-wise.
3) There is no comparing JAX-RS to Spring Rest since, as I said at 1), jax-rs is a thin API, your deployable will hold no dependency and the runtime implementation will be provided by the platform (Glassfish, Jboss etc). I have no idea why would you use JAX-RS to create a monolith and run it with jetty…
I explained JAX-RS in this article: http://www.baeldung.com/jax…
Brian Demers
Hey @amihaiemil thanks for the comment, discussion is always good!
I covered a lot of your points in the post above. For #2, I disagree, as much of Spring Web simply builds on top of the Servlet Spec. Though, I would a agree given the choice, I wouldn’t mix Spring Rest and JAX-RS in the same application. There would be however reasons for doing this in some legacy/migration cases, so I wouldn’t personally say never (but that is a discussion for a different day). For #3, I think we are on the same page. I specifically referenced Dropwizard for this reason. I’m a firm believer in an application maintaining all of its dependencies. A user could run into the same issues if they used Spring Rest in an application packaged as a WAR file. To keep things focused on the actual APIs I didn’t go into this.
Lots of good material here for other posts!
amihaiemil
> I’m a firm believer in an application maintaining all of its dependencies.
It depends, I would say that it’s the best if you keep it light and let the platform do its job. But then Oracle really was wrong in allowing vendors to implement more than the spec or allow for optional implementation of some parts if it.
It’s, in fact, Oracle’s fault that people cannot always rely on the platform – sometimes, it is simply not clear what is part of the specification and what not. And, in the end, it’s in the vendor’s best interest to make you believe that his stuff is the standard – you won’t be able to migrate in a few clicks as JavaEE advertises, thus paying more licence and whatnot.
Besides, there are many other reasons. There are people to whom Spring or JavaEE == Java, these frameworks have abstracted so much and did such a good job, to the point where developers can’t even imagine how to build a webapp without them. It’s funny, but completely understandable.
> legacy/migration cases
Yes, could be a sitiuation. We also have a funny one, where we are currently mixing JSF with React, in the process of migrating. Personally, I voted for rewriting the thing from scratch, I considered it would a much smaller effort – safly, I was the only one with this thinking 
amihaiemil
And if you really want to manage all the app’s dependencies, that could also work out OK, but then you should forget anything that is about JavaEE and just use Spring or something else 
Yannick Majoros
Knowing what’s part of the spec isn’t really that difficult. Look at your imports and you’re basically done 
Migrating in a few steps? Well, you can run into issues, but it’s your fault most of the time. If you code to the standard vs your specific implementation, that promise is actually fulfilled. I do have experience with switching containers, as well as creating server-agnostic libs. That’s really a point where Java EE shines.
amihaiemil
Well, it’s not really just knowing the spec, you also have to be careful what transitive dependencies get into the deployable, you have to avoid conflicts.
Yes, I also know JavaEE can shine. Unfortunately many do not understand it. And this is why I commented here, it seems to me this post fuels that confusion
When I say “many do not understand”, I want to say that many don’t know the difference between Java as a language and JavaEE – so your “looking at the imports” is way ahead.
Yannick Majoros
Transitive dependencies of what? If you only have spec (provided) dependencies, you won’t have implementations as transitive dependencies. It’s true for random libraries, but it has nothing to do with Java EE: you could have just the whole internet as transitive dependency. You have to be careful about unknown libraries.
Java EE is something you have to be rather professional with. In contrast to a lot of libraries, it’s not something that you can just link to your application, hack around with, and hope to master in a few hours or day. You have to read about the specification, how it works, etc. e.g. hacking around with JPA as a lot of devs do, while giving some apparent quick result, will make you misunderstand it for years. The specification is in fact very clear, which makes it quite unique in a world with a lot of unspecified frameworks. You just have to learn it. I agree this takes some effort.