What is the difference between Spring REST service, Jersey REST service and Spring+Jersey solutions?

I want to build a RESTful service/API. I used some framework like play to build it but I want to try other more efficient ways. I heard that Jersey is a common library for building a REST API, and Spring is also a good framework. But I also saw some solutions like Spring+Jersey. Thus, I am a little confused about those REST API solutions.

Can anyone tell me what is the difference among those? Jersey REST, Spring REST and Spring+Jersey REST?

My goal is building a couple of REST APIs that take JSON as input/output. I have jar file as the backend process logic to process the input a JSON/object and return a JSON/object.

Jersey is the JAX-RS API example implementation provided by Sun, while Spring REST is of course Spring's implementation of the same API/JSRs. The major difference is that Spring REST easily integrates into other Spring APIs (if you wish) such as Spring Data Rest.

There are a few noteworthy differences between them - you can "embed" Jersey Resources (known in Spring as Controllers) within each other, to enable a separate class that is responsible for the sub-path of a certain path, while this doesn't appear to be available in Spring right now (you have to define the full path). Also, in my opinion Jersey gives better "out of the box" error responses (such as why it can not map a JSON payload to a Java bean using Jackson) while Spring is a bit more configurable but plainer without some additional work.

In the end the difference in choosing between them usually comes down to - are you already or do you plan to integrate any other Spring libraries into your application? If so Spring REST is the way to go as you'll have a much easier time integrating it, otherwise it is really just personal preference which you'd prefer to use. Personally I like Jersey but the power of other related Spring projects (such as Spring HATEOAS which I highly recommend) makes Spring the better choice. I don't think there will be a real determining factor in your case.

As your "gold" target is a simple API with JSON input/output, I'd recommend you follow the Spring REST guide.

One major difference is in the area of unit testing support.

Jersey Test Framework does not lend itself for mocking server side code - For example, if your REST Resource depended on a Service, you would like to mock the service when testing resource methods. However, Jersey Tests run a separate container and unit tests sort of make calls to the running instance of your REST resource - at this point of time, I have not found any documentation or way for mocking server side code.

On the contrary, Spring MVC tests do not require any containers - and are more well integrated with its controllers. Dependency Injection can be used to inject mock services / DAOs to have better unit tests.

I also find that documentation on Spring projects are more mature when compared to Jersey.

One subtle difference is in the instantiation of the resource (Jersey) or controller (Spring) objects.

Jersey new's a resource object for each request. Whereas, by default Spring treats controllers as beans with default scope of singleton. This can be overridden with a @Scope annotation (although if you do that it will get flagged by Sonar).

This default behavior of Spring has bitten our application several times. With the controller class being a singleton, all class members are effectively static. So values set handling one request will still be there for the next.

This is something to be aware of if your using Spring. My suggestion is to @Scope the controller class as prototype, even though that will earn you a warning if you do Sonar scans.