[Query on Discovery of RESTFul Services] Leonard , Sam

Hi Leonard,Sam

After creating the RESTFul service can I publish it to the UDDI? Can we generate WSDL's out of the deployed RESTFull Web Service? How will be prospect user of the webservice be able to discover their URL's where the resource is deployed and the verb to be used?

Sorry, If I am sounding to basic.. But just trying to co-relate my exisinng SOAP Based Web Service knowledge to the new world of Rep State Transfer

*********************
Regards,
Dinesh Sundrani
---------------
SCJP 1.5 [86%]
SCWCD [95%]
SCDJWS [98%]
*********************

The question you've asked goes to the heart of the difference between
RESTful web services and today's SOAP services, so this might not be
terribly intelligible. I will try my best.

A typical SOAP/WSDL service deploys a single "service" object (the
SOAP endpoint) and a WSDL document. The WSDL document points to the
URL of the service object, and describes the format of the documents
to be submitted to that URL.

A RESTful web service works more like a web site: it deploys a large
(probably infinite) number of objects, each with its own URL. The
client can get a description of an object by sending a GET request to
its URL. The description will contain information about the object,
but it will also contain links to related objects, and forms that
explain how to modify the object. The information that would go into a
WSDL file (the URL of the service, and what document formats the
client should use) is distributed among the many objects. Each object
describes itself.

The client starts at some known "home page" object, and follows the
cues to other objects. There are a number of technologies that a
service can use to convey these cues: HTML, WADL, "anyURI" nodes in an
XML document, etc. WSDL 2.0 technically falls into this category, but
it's almost never used for this purpose.

This leaves open the question of how the client knows the "home page"
URL, and how the client knows that the object at the other end of that
URL will help the client reach its goal. The closest RESTful
equivalents to UDDI are search engines like Google. These work well
for the WWW, connecting human beings to URLs that help them reach
their goals. But search engines don't really pick up web services. For
a variety of reasons this problem has not been solved. I expect that
when it is solved, the result will look a lot like a search engine, or
be part of a search engine.

To answer your specific questions:

I don't know if you can publish the URL to a RESTful service to UDDI
(Sam might know). Assuming you can, it's not going to look like other
services in the directory.

You can write a WSDL 2.0 file for at least some RESTful services, but
it's usually more trouble than it's worth. A framework that makes it
possible to generate WSDL for a RESTful service is conceivable, but I
don't think there are any.

Once the user of the web service knows the main URL for the service,
they can GET that URL and see links to other URLs. They will also see
forms that tell them what verbs to use.

What I've described is an idealistic scenario. In most real
services today, some of the links and forms are missing. You have to
read the equivalent information from a natural language document, and
program the information into your client.

I hope this helps. The book covers these topics in detail, especially
in chapter 10.

I don't know if you can publish the URL to a RESTful service to UDDI
(Sam might know). Assuming you can, it's not going to look like other
services in the directory.

The UDDI specification is pretty much description language agnostic, just like the specification of WSDL is schema language agnostic; that being said, Leonard's second sentence comes into play: if you wanted to publish a WSDL that didn't use XSD, don't expect much interoperability. Similarly, if you want to publish your WADL file as a UDDI tModel, don't expect much interoperability.

Thanks Sam, for the Interoperability disclaimer

It might also be useful to bear in mind that good REST implementations are often self-describing, so only a single root URL is needed to get started.

The main trick seems to be to use convention rather than configuration. For example it's common on the web to treat any GET request ending with a '/' as a request for an index of resources.