This question already has answers here:
Servlet vs RESTful
(3 answers)
Closed 6 years ago.
I have created many REST web services providing JSON before using PHP and NodeJS and I know the concept.
Now I want to re-implement those web services using Java instead. After doing some research for how to implement web services in Java, I found some standards or libraries like JAX-RS, Spring or Jersey. However I not know the difference between all of them.
I wonder why we do not make a simple servlet which will be called through HTTP request and returns the result in the JSON format. And if I wanted to use one of these standards, what would be the best choice to implement web services that accepts HTTP requests and returns JSON?
You can use a stone to drive a nail into the wall. For sure you can. But why would you do that if you have a hammer available? Using the proper tool will make your life a lot easier.
In a similar way, you can create REST applications using only the Servlet API. However, there are other APIs that are designed to create REST applications. So, why don't you use them?
JAX-RS and Jersey
JAX-RS, currently defined by the JSR 339, is the standard Java API for creating RESTful web services and it's built the top of the Servlet API.
It's important mention that JAX-RS is an specification. In order to use it, you will need an implementation, such as Jersey, which is the reference implementation.
A few resources that may be useful:
JAX-RS 2.0 specification
Jersey documentation
Spring Framework
The Spring Framework allows you to create RESTful web services and it can be easly integrated with other Spring projects.
A few resources that may be useful:
Spring Framework website
Spring Framework documentation
Guide to build a RESTful web service with Spring Framework.
Other resources you may consider useful
Why use a framework for RESTful services in Java instead of vanilla servlets
Why use JAX-RS / Jersey?
Spring 4 vs Jersey for REST web services
Difference between JAX-RS and Spring Rest
You can do it using Servlet API actually. But you won't get all the benefits of JAX-RS like url mapping, parameters injection, ... You would have to write all this "by hand".
By the way, the difference between JAX-RS and Jersey is that JAX-RS is a specification, a standard and Jersey is an implementation of that standard. There are other implementations as well (RestEASY for example). Spring also has a module for REST services.
Related
In one of my projects we have written REST API based on the Jersey REstful WebFramework. In some situations we might want to convert those JERSEY based REST API to the Apache CXF.
If all REST APIs (means written Interfaces and their implementation) are working fine with Jersey RESTFul Framework, then will just replacing the framework (e.g. possible jars, dependencies on POM) to Apache CXF work ?
What are the major things a developer should consider on such a porting?, Is my question relevant ? (My past experience related to the C++ system side where we ported APIs to different platform e.g. BSD Sockets API, pThread APIs. If all of these Jersey,Apache CXF,Restlet following same JAX-RS specification then porting should work ?)
I have developed RESTful web services in two ways:
used a class that extends javax.ws.rs.core.Application without defining a web.xml file, using Glassfish.
haven't used javax.ws.rs.core.Application but included a web.xml and a Jersey implementation, using Tomcat.
Is there a preferred way of building RESTful web services with JAX-RS?
Using the javax.ws.rs.core.Application class is the preferred way and also the only portable way of configuring resources and providers in a JAX-RS web service,
so if possible that would be the recommended way to set it up.
But that works well only in JAX-RS aware servlet containers or application servers, for JAX-RS non aware servers you need other ways for deployment and that most of the times means some proprietary servlet class of the JAX-RS implementation you are using.
To get more details on the subject, see for example the Jersey documentation, Deploying a RESTful Web Service (for Jersey v1.x) and Application Deployment and Runtime Environments (for Jersey v2.x).
I have to implement SOAP based web services for a project. We are considering different options like axis2, ejb as a web service, jax-ws but not really sure about the advantages/drawbacks of these options. Can someone please help in this regard.
It would be great if someone can point to any other alternatives for implementing SOAP based webservices.
Thanks in advance,
-Csn
For me, the easiest way to expose a web service is creating an EJB with annotations (JAX-WS) if you are using a Java EE server like JBoss.
Consuming a WS is a bit different but I prefer JAX-WS too, because Axis2 throw exceptions if you use complex parameters (classes) and you add an attribute. JAX-WS instead calls every 'get' and 'set' for the serialized xml. If no 'set' is implemented, no problem.
That's an advantage for backward compatibility.
I would highly recommend to use Apache CXF for developing SOAP web services. This stack is based on JAX-WS but has much more features. CXF has an excellent integration with Spring. There are a lot of documentation on the internet how to create web services using this framework. If I would be working on completely new web service I would definitely choose Apache CXF.
I have web application designed using spring 2.5.5 MVC, JBoss server. I want to expose my spring services (like add/update User, comments, documents, etc.) using WebService for EAI. Requirement is like any third-party application should be able to perform operations in my web application after authentication/authorization.
I have novice knowledge of SOAP (Axis2) and REST (Jersey), however i am not sure which will be best suited for my application.
Cheers
We are using Spring 3.0 actually. But former using Axis2 with Spring 2.5.x.
You might review our stack at http://incubator.apache.org/openmeetings the axis.
We simply integrated the regular Axis2 configuration into the web.xml and build a Facade to load the spring beans into the Axis enables Web-Service and forward the calls to the Spring enabled context that way.
Comparable to https://svn.apache.org/repos/asf/incubator/openmeetings/trunk/singlewebapp/src/org/openmeetings/axis/services/FileWebServiceFacade.java
It is not the perfect solution, the Axis2 documentation also contains other ways to load the Spring context in the Web-Service enabled class, however it was never possible to make that work stable so we decided for this workaround.
i am new to REST Service development. I compared the development mechanism for both REST and WS web services and i found that you can create a WS web service using WSDL file that is the top down appraoch (Correct me if i am wrong) and using bottom up approach also, that is generating the classes manually.
But when it comes to REST web service development you have to follow bottom up approach only that is generating the classes manually. NetBeans IDE provides certain wizards for creating REST web service quickly from databases, entity classes and patterns.
I had also seen when you are developing web service in eclipse and you are using wizard in eclipse IDE, you can create a REST web service from WSDL file. I found this very strange. My question here is what are the approaches we can have for creating REST web services. Can we create REST web services using top-down and bottom up approached. If yes then please provide me details.
Thanks.
It is possible to describe a REST service using a contract. This is the intent of WADL and WSDL 2.0. WADL is specifically a REST contract, whereas WSDL 2.0 evolved from the original WSDL spec. to support all HTTP bindings. Since REST services rely on the use of HTTP methods and headers to exchange messages a WSDL 2.0 contract can work. There is a really good explanation here: http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl
For development of REST services, I'm not sure if NetBeans, Eclipse or other tools specifically support automated REST service from WSDL generation. I would imagine that most are still intended for SOAP service creation. At this point I think WSDL 2.0 and WADL can be used to describe a REST service, but are not intended for automated generation of a REST service.
REST services are simple HTTP request/response,and therefore don't require complex stubs. In most cases it would probably take more time to write the WSDL describing the REST service, than it would take to write the REST service itself.