WSDL necessary?

[Eugene Wright]

I'm a bit new on webservices in general so bare with me as I'm trying to make sense of a current process. We have jpd out there which another application (.NET) is importing the namespace and utilizing one of the methods. The method simple takes in an HTTP GET and sends back some data in xml format. There is no WSDL file associated with this program, so is this still considered a "web service?" If not, what's the difference here and how would this be handled differently with a WSDL? Thanks

[Eugene Wright]

Well I guess I can answer part of my question and say, if a customer outside of our firewall needed access to our jpd, it could be provided via a WSDL. However, when dealing with internal only customers, is it normal practice to provide a WSDL?

[William Brogden]

so is this still considered a "web service?"

I would call that an example of a RESTful web service - assuming that the GET does not change any resource on the server.

WSDL is rather clumsy when describing a RESTful web service - commercial examples seem to prefer descriptive text and coding examples.

Bill

[Dan Drillich]

RESTful Web services: The basics says -

This article suggests that in its purest form today, when it's attracting this much attention, a concrete implementation of a REST Web service follows four basic design principles:

- Use HTTP methods explicitly.
- Be stateless.
- Expose directory structure-like URIs.
- Transfer XML, JavaScript Object Notation (JSON), or both.

Regards,
Dan

[William Brogden]

Note that a RESTful web service is free to serve ANY kind of resource, not just XML or JSON.

Bill

[Jimmy Clark]

The Web Services Definition Language (WSDL) is an XML-based markup language used primarily for SOAP-based web services. However, there are now multiple versions of the language which include support for RESTful web services.

Keep in mind that in the context of RESTful services, there is no "technical" requirement to use a WSDL instance. Here it is for humans to read only, not computer software.

[Nick Watts]

If all the parties using a web service understand exactly how to format requests from your web service and parse the response, then you don't technically need a WSDL. However, the WSDL incorporates all of that precise request/response formatting in its definition in a way that is easily digestible by many tools like JAX-WS. Especially with SOAP messages, the WSDL is the key that allows you to use all kinds of tools that know how to deal with web services. So if an informal writeup on your web service's interface is acceptable, you don't have to use a WSDL -- especially if you're not using SOAP messages. If you're using SOAP or you want to use tooling to work with the web service, you'll need a WSDL.

[Deepak Bala]

Nick Watts wrote:If all the parties using a web service understand exactly how to format requests from your web service and parse the response, then you don't technically need a WSDL. However, the WSDL incorporates all of that precise request/response formatting in its definition in a way that is easily digestible by many tools like JAX-WS. Especially with SOAP messages, the WSDL is the key that allows you to use all kinds of tools that know how to deal with web services. So if an informal writeup on your web service's interface is acceptable, you don't have to use a WSDL -- especially if you're not using SOAP messages. If you're using SOAP or you want to use tooling to work with the web service, you'll need a WSDL.

Yep. Tooling is the key word here.

Also lookup WADL - http://en.wikipedia.org/wiki/Web_Application_Description_Language

WADL is not yet widely supported. It has the advantage over the more complicated WSDL in that it does not impose any further level of abstraction on the service description; however, as tools become available for application development with WADL, it is likely they will include ways of automatically generating WADL, and this risks imposing an RPC style on it, going against the intended simplicity of WADL.