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
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.
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 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.
