Hi I am working REST Services and I just want to know how can I provide the web descriptor for REST Services. It will be great if their is some API that can directly produce the WSDL for REST Service.
I am using Spring STS for development is their anything inbuilt in Spring STS.
I have few more questions for the same:
Is it feasible to provide the descriptor for REST Service.
Providing the descriptor is not the violation of REST or HATEOS architecture style.
What are the different ways to achieve this.
REST services shouldn't use WSDLs. WSDLs are used for SOAP Web services, not for the REST design style.
Instead of using WSDLs, REST APIs should be discoverable.
Possible duplicate of this Stackoverflow question.
Though it's possible to generate some sort of WSDL if you use WSDL 2.0, people don't seem to generally describe REST services with WSDLs. This is because REST services are usually HTTP requests with GET/PUT/POST/etc methods.
At best, people can generate something called a WADL, but generating WADLs hasn't really taken off in the general community.
There's no de facto standard for describing REST APIs. If you need to automate it, I recommend looking up how to generate WADLs.
There are also other solutions/alternatives out there used to document and describe REST APIs. It all depends on what your actual requirements are.
Some other good Stackoverflow questions to explore:
What is the reason for using WADL?
Why the slow WADL uptake?
Related
I feel a bit naive for asking, but I'm trying to get a better understanding of web service frameworks.
Do you absolutely need a Jax-WS/RS reference implementation (like Axis/CXF) to run a web service application on a server like Tomcat? Is it at possible to get by with a collection of your own imports (Spring Framework libraries, Java EE libraries, JAXB, etc.), provided that you do not need things like wsdl2java auto-generation?
Are Axis/Axis2/CXF an essential part of any web service project, or just a nice to have?
I've used CXF and Axis in the past, but both were buried so deep beneath Spring and my IDE that I never got a clear picture of where the web service framework ended and the Spring framework/dependencies began.
The documentation on the web service frameworks also doesn't tell me much, as it focuses on what they frameworks can do, vs. how you might be able to get by without them.
Thanks
If you want to deploy a web application on Tomcat then the bare minimum you need to do is implement the javax.servlet.Servlet interface.
If, by web service, you mean a SOAP service, then there is more you will need to do (well, to be specific, you will need to implement a Servlet which behaves in a certain way). There are two primary features that frameworks like CXF/Axis provide (and a myriad of smaller features):
Serialization/Deserialization
Bare HTTP requests are available as streams of bytes (InputStream/OutputStream). In many applications you will want to convert those byte streams into Java objects. With JAX-WS this is done by requiring the input/output be XML and using JAX-B. Other frameworks (e.g. JAX-RS) can work with other input/output formats (like JSON).
Routing
An HTTP request consists of a URL (perhaps with query parameters), headers, an entity body, and various metadata around the call itself (e.g. IP address, session object, etc). Somehow this request has to get mapped into a method call in your service, with parameters. In JAX-WS this is done by mapping parts of the SOAP envelope with information about your service endpoint gleaned from reflection.
So...
If you want to skip using Axis/Axis2/CXF you will need to find some way to implement those two features yourself. You will almost certainly also be surprised by the amount of tiny details involved in solving those problems (e.g. SOAP RPC/encoded message format versus document/literal format, etc.)
CXF will also implement a number of SOAP extensions, the most prominent of those being ws-security (although many people end up using Spring security and bypassing formal SOAP security anyways).
Alternatives
Your question is a little vague so I'm not certain what you're after but there are some alternatives.to just using Axis/CXF...
Different JAX-WS library
There are other JAX-WS providers out there. For example, you could use the JAX-WS RI although your experience is not likely to be too much different than CXF/Axis.
Different web service technology
Rather than using SOAP you could use a RESTful framework like JAX-RS. This can be particularly helpful if you want to understand more the connection between HTTP and your calls. There are a myriad of articles discussing the benefits/drawbacks of SOAP vs. REST so I won't go into that here. In general JAX-RS is a lot more clear and customizable but requires more work to configure.
I'm trying to write restful JSON webservices. I have implemented a few using CXF, however with CXF, JAX-RS the dependencies are bloating up the single page web application. Is there any easy way to compose restful services without any of JAX-RS and in particular without using JAXB based marshalling/unmarshalling.
If CXF is providing more capabilities than you need, look into Jersey or Restlet, both of which may provide a library that specifically suits your needs. Note that these are going to implement the JAX-RS specification.
Other guidance may depend on your environment. You very well could write a servlet and handle the JSON yourself, see here for a discussion: Reasons for not directly writing Servlets for creating a REST API
Given a task at work to understand the usage of java webservice or aka JAX-WS in eclipse IDE with axis2 tool and using soap UI to view the messages.
looked at few examples on [http://docs.oracle.com/javaee/6/tutorial/doc/bnayl.html][1] and also tried a example to retrieve database info to soap ui message but still not confident to say that I understood everything.
Need clarity on the points below:
What is axis2 tool and what it does to help when combined with eclipse ide
soap ui - as the name says its a user interface to view soap messages if I am not wrong, but what is other way of running a webservice with out soap ui and what is the convenience for a developer to adopt to soap ui
As I am simultaneously learning webservices with burden of understanding tools at the same time please guide me few good tutorial sites.
Thank you
I did more or less the same few years ago. My experience is as follows (your mileage might vary):
you need to understand XSD well
when you look at few WSDL examples you will figure out that WSDL is XSD + little overhead, which is almost always the same
it helps to play with examples, I personally found axis/axis2 bit clumsy, if possible take another provider, e.g. JBoss or reference implementation (Glassfish), but perhaps you will have to use axis afterwards, so better to stick to it from the beginning. SOAP UI is ok, you use it as client.
I read one of the books on axis and one on JAX_WS alone. I would recommend the JAX-WS book, which did good job covering all the theoretical background and provided lot of examples. Bit boring read but good for getting started and as a reference.
Axis2 is WebService provider. It's a bunch of libraries and tools which on one hand generate for your the needed artefacts (Java from WSDL or the other way around) and on the other when packed into a web war allows you to publish a webservice by deploying the war in a container, e.g. tomcat. Yo might start by deploying one of the examples in Eclipse into Tomcat (running in Eclipse or outside) and write and run a Java client against it. Writing a simple client against a running service is good alternative against SOAP UI. SOAP UI helps you to understand the JAX-WS at protocol (SOAP) level. For playing with axis (not axis2!) was the axis book helpful.
Instead of SOAP WebServices, go for RESTful WebServices. RESTful Web Services are build to work best on the web.
REST is almost always going to be faster. The main advantage of REST is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence.
REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. However, the clients have to know what to send and what to expect.
REST has no WSDL interface definition
REST is over HTTP,
but SOAP can be over any transport protocols such HTTP, FTP, STMP, JMS etc.
"In general, When you're publishing an API to the outside world that is either complex or likely to change, SOAP will be more useful. Other than that, REST is usually the better option".
In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web.
REST is an architecture. REST will give human-readable results.
REST is stateless. REST services are easily cacheable.
SOAP is a protocol. It can run on top of JMS, FTP, Http.
The REST architectural style constrains an architecture to a client/server architecture and is designed to use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol.
I don't know "anything" about WebServices in Java and eventually I need to do some REST work in Java and well I want to strart learning it this weekedn d:) So my question is do I need to first learn Java web services before I can learn REST webservices? what are the prerequisites stack of knowledge I need to learn first? and your suggested resources.
Thanks
The Java Web Services stuff only have a small relationship with REST services.
Both are "remote services" for the web, so they share the same kind of problems: object representation, security, error handling, etc.
But you don't need to learn the complexities of WS-* like service definitions (WSDL), SOAP... and a large list of stuff.
The small relationship between REST and WS in Java, comes when you want to "automatically" convert objects to XML or JSON. Because Java REST frameworks based on JAX-RS can do that by using JAXB (Java XML Bindings) an object conversion framework used also in the Java WS framework. But you don't need to use that object conversion stuff either.
Some JAX-RS compatible frameworks -like Apache CXF-, can be used also to do JAX-WS (the Java standard API for WebServices). But note that general services frameworks like CXF, have to deal with other complexities (like support for different transports) that you don't need to learn.
What you need to learn first?
Java Servlets: You don't need to be an expert on servlets, but REST services are mounted over the Java servlets infrastructure and knowledge about it will help.
Dependency injection (DI): When you start doing REST resources that access to databases or other services, you'll want to pass some collaborator objects to do that. Most of the frameworks resolves that problem by using DI. For example most of the JAX-RS frameworks can be used with Spring or Guice.
TIP: I found lots of people that uses Spring or Guice because.. tutorials shows that is the correct way to do it. But they don't know what are trying to resolve, and end with complex unmaintainable stuff. My recommendation is that before using any DI framework, first learn the concepts behind them.
(Optional) A little bit of JavaScript and AJAX. If you plan to use the REST services from a web page, is good to learn how they are going to be used.
Edited: To include a mention to Apache CXF, and use the term JAX-RS instead of Jersey that is a specific implementation.
There's a good summary of the Richardson book here: http://martinfowler.com/articles/richardsonMaturityModel.html,
Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?
Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )
The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.
An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.
As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).
You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.
Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.