We are planning to make a new application with spring 4.0.6 version. We use controller that can return "XML" or "JSON".
In the previous project we have successfully implemented Jersey with Spring for REST support using JAX-RS API, but after reading a few articles and suggestions from seniors they said spring is providing pretty good REST support.
Some of the points that really confused me if I use Spring REST support without using JAX-RS and Jersey are:
How marshaling and unmarshaling done in Spring MVC ?
Is it necessary for marshaling or unmarshaling need to use jax-rs.
If marshaling and unmarshaling are automatically handled by spring then how does it know about xmlRootElements.
I am still confused if Spring proving very good support of REST then why do people still go with Jersey for REST?
Really looking to know more in details.
If I said anything wrong please ignore it.
Explanation with example is really helpful.
I'd say both Jersey and Spring MVC are great - each project has its own style and strengths. Anyway, Stack Overflow is not the right place for asking subjective comparisons (your question would be closed quite quickly). If you're already using Spring for everything else and are not required to use JAX-RS, then Spring MVC makes total sense.
Regarding features like (un)marshalling, JAX-RS is just a spec after all - other libraries can offer similar features without implementing the same API.
Instead of MessageBodyReaders/Writers, Spring MVC is using HttpMessageConverters to handle (un)marshalling REST resources. Spring MVC handles content negotiation and chooses the best available converter for the job (you can annotate methods to hint at what media type they produce/consume).
No, it's not necessary to use JAX-RS to (un)marshall resources. In fact, JAX-RS implementations and Spring MVC use third party serialization libraries to do the job; so it's not tied to a particular standard.
In its 4.0.6 version, Spring supports many HttpMessageConverters, with Jackson for JSON, JAXB for XML and many others. Spring 4.1.0 added more HttpMessageConverters:
Jackson is now available for both JSON and XML
Google Protobuf
Gson for JSON, as an alternative to Jackson
To answer your last point, #XmlRootElement is a JAXB annotation and is not part of JAX-RS. Spring supports JAXB.
For a more complete example with REST in Spring, check out this getting started guide (you'll get a complete example running in 10-15 minutes).
Again the last part of your question is quite subjective - there are many popular solutions for building REST services in the JVM, not just Jersey and Spring (Dropwizard, Play! Framework, etc).
AFAIK Spring REST support is based on Spring MVC and its not JAX-RS implementation while Jersey has implemented JAX-RS specification.
Those having Spring (Core, AOP or MVC) in their project chooses Spring ReST support over JAX-RS implementor.
I recommend Jersey as its mature, implements JAX-RS and is easy to use.
Related
I was going through this tutorial https://www.baeldung.com/spring-graphql in order to configure graphql and map objects directly to POJO, however with the new packages from https://github.com/graphql-java/graphql-java-spring the interfaces used in the tutorial don't seem to be there anymore.
Is it possible to use the same techniques (maybe using an additional package) to map grapqhl request to objects and configure datafetchers in an easier fashion than manually ?
Note that I would like this to be webflux compatible not webmvc.
The Spring Starter that Baeldung tutorial is using is coming from graphql-java-kickstart, and it is not the same as the official graphql-java Spring Starter.
Their programming models are different. The Kickstart one relies on graphql-java-tools, while the other one uses graphql-java directly. So you can just keep using the latest version of the Kickstart Spring Starter. Not sure whether it works with WebFlux, but I'd expect so.
There's also my project, GraphQL SPQR Spring Starter and a sample app here. The latest version (0.0.4) works with WebFlux, but for queries and mutations only, subscription support is coming.
I need to implement a java soap client with message level encryption. This will be running in a slightly older app that has some spring 3 controllers and jax-ws web services.
I need to add message level encryption and so far most of the hit on searches point to cxf. I didn't want to add another framework to the project.
There must be another way to do this.. This subject has been difficult to find good answers on.. any help is appreciated
The standard for SOAP message-level security is WS-Security, so you should use a WS-Security implementation. Since you are already using Spring, look at the Spring WS-Security extension:
https://docs.spring.io/spring-ws/site/reference/html/security.html
You would need to add the Gradle/Maven dependency spring-ws-security to your project.
However, as far as I know, this Spring WS-security extension is quite limited compared to CXF, e.g. it does not support WS-Policy/WS-SecurityPolicy which allows to configure the security policy in a standard way. Also CXF is already integrated with Spring, so I recommend it on the long term. Check the doc if you are interested in the alternative:
http://cxf.apache.org/docs/ws-securitypolicy.html
I have a spring based project that need Rest API support for developing Rest client. This is a very high load application and I need a Rest implementation that with good performance. I've found in many article like one here that CXF is a great performance wise but initial effort in configuration and POC seems to be to much. Haven't found a lot of documentation regarding the API usage.
Can any one suggest weather I should use spring or CXF.
You should also try Restlet and Jersey. By doing some demo projects with each one of them, you can find out which one best suit you.
In one of our projects we are using the spring mvc. The spring mvc has inherent support for REST web services. I am looking forward to some insight/suggestions on how does Springs mvc's REST support fare when compared with the other popular framework like RESTEasy, RESTlet,JAX-RS etc.
The first big differentiator is that Restlet and RESTEasy both provide implementations of JAX-RS. You can write JAX-RS code that either of those frameworks could run and not have to change anything. Spring MVC is a separate API that doesn't implement JAX-RS. It does provide most of the same functionality from what I've seen. Of course, Restlet also provides its own non-JAX-RS based API which is nice too.
I found this seemingly thorough comparison of Spring MVC and JAX-RS at InfoQ that might interest you. I would say, if you are already using Spring MVC and it meets your needs in the REST department, stick with it until you find a need to look for something else.
I have a question regarding RESTful client implementation.
At this moment I have developed the server using RESTeasy and EJB. Method return JSON in much case. And now we are starting backend development(WEB). And can't select a framework for this, that supports authorization, authentication...
Could you suggest a pattern, framework, approach etc..
If you looking for a Java web framework that fits your existing technology (EJB) you should take a look at JSF and WebBeans (note though that JSF does not expose RESTful URLs for its actions/controllers).
However since you also mentioned REST I guess you just want a backend framework for your services that can handle user security and auth. In this case you should take a look at spring (in particular spring-security and spring-web). Most JAX-RS implementations have good support for spring, although I should mention that spring itself has a splendid REST framework that of cause works very well with their other offerings.
If on the other hand you want a framework that can handle security in the context of a EJB application that exposes a RESTful service, then you are in a tough spot. RESTful applications are meant to keep most of the state at the client, in contrast to most EJB apps that frequently uses state-full session beans. You can integrate JAX-RS with stateless or singleton EJBs and then either use spring-security to handle the security/auth or use the <security-constraint> in the web.xml as described here