This question already has answers here:
RESTful Services - WSDL Equivalent
(8 answers)
Closed 3 years ago.
I am implementing a web service and I have implemented both a REST and SOAP version to see which suited my needs.I have decided to choose REST because of its simplicity and that I will probably be developing an iPhone app to consume it. My question is simple really, is it possible to create a WSDL or WADL for my REST service and is it necessary?
Thanks
With a good RESTful service, it's not necessary to generate WADL (let alone the much-less-well-fitting WSDL) for it because it will self-describe. By “self-describe” I specifically mean that it will deliver documents describing all the (relevant) resources published by the service, and that using a standard HTTP OPTIONS request on any of these will produce basic information about how to interact. The only real benefit to using WADL is that it allows the caller to discover the schemas for the complex documents it needs to work with ahead of time; REST itself provides no help there (and some RESTians believe that doing such things is counter-productive, which I'm not sure I agree with).
Of course, that doesn't capture the deeper interaction patterns, but neither do the vast majority of WSDL descriptions of services so no change there.
For the record, I use Apache CXF to create RESTful services (using JAX-RS) and that publishes WADL for them.
The W3C has made a formal recommendation for a REST documentation standard based on [WSDL 2.0][3]. Here is a quote from the IBM article:
The term Web services is typically associated with operation- or
action-based services using SOAP and the WS* standards, such as
WS-Addressing and WS-Security. The term REST Web services generally
refers to a resource-based Web services architecture that uses HTTP
and XML. Each of these architectural Web service styles has its place,
but until recently, the WSDL standard didn't equally support both
styles. The WSDL 1.1 HTTP binding was inadequate to describe
communications with HTTP and XML, so there was no way to formally
describe REST Web services with WSDL. The publication of WSDL 2.0,
which was designed with REST Web services in mind, as a World Wide Web
Consortium (W3C) recommendation means there is now a language to
describe REST Web services.
As #GiuliaDiFederico said, "of course it's possible" (with WSDL2), showing a good source link about how to do. #DonalFellows, by other hand, does not encouraged the use of WSDL...
I think the use of WSDL is a question of
FORMALIZATION LEVEL: with WSDL you can express more formally all relevant details of your webservice.
STABILITY LEVEL: if you need long term contracts, and avoid risks of changes in the enviroment where your webservice is exposed, WSDL helps to mantain stability.
NEED FOR STANDARDS: if customers prefer webservices that can be said "standard compliant", use standards. The only one is W3C, and W3C requires XML, SOAP and WSDL.
RestDoc tries to create a simple documentation framework for REST resources.
A browser is available via restdoc-renderer.
It also offers Java annotations to enable on-the-fly creation of RestDoc documetnation. Implementations are available for Jersey 1.x and JAX-RS 2.0.
Of course it's possible, but for answer if it is necessary or not, you didn't provide enough info.
I suggest you to take a look on the ibm's developerworks site that provide an interesting article on subject
Strictly, with WSDL 1.0 you can' t, but with WSDL2 you can, because was developed for accept this kind of demand,
"... WSDL 2.0 in a WS-I profile that addressed the requirements
for REST style Web services. The addition of GET in SOAP 1.2 and several
additions in WSDL 2.0 such as operation safety, the ability to describe
messages that refer to other Web services, and the improved HTTP binding
now make it possible to describe REST style Web services.", Arthur Ryman.
I think WSDL is not appropriate for REST and WADL is not necessary. HTTP exposes already what WADL could describe in a separate file. For example the "Allow" header returns allowed HTTP method, and Content Negotiation is for choosing the right format.
WADL is not necessary. But, If Client side code is already present in an application and you want to make a new rest call then it is good practice that you use wadl for generating the client side java stub(POJO). By this way, client side POJOs will be in sync with service side POJOs. For example, If you are replacing EJB/SOAP service call with Rest service call in an existing application then It is very safe and good practice to use WADL.
You can generate client side java stubs from WADL by using wadl2java maven plugin.
I am new to consuming web services. I am trying to consume a SOAP service. This is currently in the test environment. What I have done is
Use wsdl2java to generate a wsdl that I have copied to my domain folder.
Use the API to send requests and receive responses.
What concerns me is do I need CXF or Spring WS to wire the service or is what I have sufficient. I am asking this because I have seen elsewhere like
What I don't get is where I would generate property when environments are switching from development to QA to production. And do I need to use CXF or Spring WS or are the annotated classes (#WebServiceClient sufficient) to consume the SOAP service. Basically, how to connect to different endpoints.
I apologize if this is rudimentary question. Thanks.
Spring-WS and Apache CXF are primarily useful for creating web-services. They are alternative web service implementations to the one that ships with Java6.
You can use them for writing clients, but there's not really much point, unless you're really keen on the alternative API that those provide.
The standard JAX-WS artifacts generated by wsdl2java should be perfectly sufficient for what you need.
As for your second question regarding how to target different prod/QA endpoints, you should ask a separate question for that, with full examples of what you have.
I've been at this for a little while and my mind has gone to mush.
I'm wondering if anyone can help me out here. I'm trying to make a Java Web Service (using its own HTTP server and not something like tomcat), that supports Metro and Jersey. This way a client can connect to the web service anyway they want whether it is SOAP or REST.
I've got the metro part down so it can support Doc/Lit wsdls and RPC/lit wsdls but I've having some difficultly understanding the Jersey part so it will support REST/xml and REST/json
Also the idea is that there would be one class where all the endpoint methods are written in and other classes would extend it.
Has anyone used these two combined before? Can you point me the direction of a decent article or do you have an example yourself?
Thanks
Metro is a implementaion of JAX-WS used mainly for WSDL/SOAP based webservices.
Jesery is a implementation of JAX-RS used maily for Restful based webservices.
I have used both in the same project but for different purposes. You can also use apache httpclient for restful services, but jersery provides lot of useful annotations for converting to json, xml etc. Hope it helps.
I am a bit confused about what you mean when you say you want to support Jersey. Jersey is an implementation of JAX-RS (JSR-311). Do you mean you want to support JAX-RS?
Actually I have to work with a web service written in .NET with WSE 3.0 and digital signature and encryption of soap messages. I have to make a java client in order to consume the .net webservice.
I have the wsdl file, a CA.cer file, a certoencrypt.cer file from the provider and I would like to know where to start in order to make the java client so it can consume the web service.
Any help would be appreciated.
I don't know anything about wse 3.0, but that should have no limitation on creating a client to call the web-service from java. Generally, you should start by creating web-service proxy classes using something like JAX-WS RI (I'd recommend this since its packaged with JDK 1.6) or Axis2. Another useful tool for web-services development is SOAP UI.
From within soap ui, you can generate the above mentioned proxy classes using a variety of web service frameworks including the 2 mentioned above. once you have those classes generated, your going to want to reference them from your project and use them to make your web-service calls. there are examples of how to do this all over the internet, and the implementation details will depend on the framework you choose to use.
I need to implement a SOAP Web Service on Jboss Seam 2.1.0. The idea is to export an Stateless bean method as a Web Service.
However, I have found two approaches.
First one, is to use the Seam's own web services annotations. The problem of this is the lack of documentation.
Second one, is to use Enunciate. It's a lot better documented, but I feel that this is not the standard manner.
So, which one is the best approach? Have I missed something? Is there more documentation around about the JBoss Seam "standard" SOAP web services implementation?
Thanks in advance, regards,
(Sorry, as I'm new here, I cannot post hyperlinks)
I've always used JAX-WS which works very well with EJB3. Annotate your stateless bean with #WebService, your methods with #WebMethod and your parameters with #WebParam.
The only trick to getting it to work with Seam is if you need authentication. In that case I've defined a SOAPHandler in standard-jaxws-endpoint-config.xml. You'll need to pull the username and password information out of the SOAP header and manually authenticate with Seam.