Paul Prescod wrote:
>
> Interesting point.

Whoah!

Are the lines of communication cracking open, if even a tiny bit?

;-)

> For instance if I
> do a createStockTicker("RUBY") message, can any existing SOAP toolkit
> return:
>
> <NewTickerURI>http://www...../RUBY</NewTickerURI>
>
> And then have the client do method calls against the newly created
> endpoint.

Would Axis count? When Axis is deployed as a servlet, one can map a
url-pattern to the AxisServlet. One can then deploy a transport specific
handler which obtains the relative path and does something appropriate with
that information.

> WSDL certainly does not support strongly and statically type
> declaring this interaction. That's its biggest flaw when it comes to
> REST.

Several points. First, WSDL need not be strongly typed. I provide a
complete and working example of this in
http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11\
.html.

Second, it is possible that a WSDL could be generated dynamically for such
URLs. And finally, WSDL is not required.

> I've thought about the idea of a REST-on-SOAP
> and found a few problems

I won't go point by point through these at this time. I feel that you do
have a legitimate beef about SOAP over HTTP, but continue to make
distracting and somewhat irrelevant points, and I would like to focus first
on the core issues. For example, a position that SOAP over HTTP should
never be used is one that I see as internally self consistent, but not one
that says that HTTP should have a default port, but SOAP over HTTP should
not.

The next step is to discuss the relationship between HTTP and REST. There
are not synonymous. In particular, there are quite a number of uses of
HTTP that are inconsistent with REST, including most CGI based
applications, and by implication most servlets, ASPs, ColdFusion
applications, PHP applications and the like. And don't even begin to
mention cookies...

Yet none of these seem to inspire the vitriol that SOAP has received.

> Actually, I am interested in this also, but I have a feeling that we
> would disagree on the virtues of SOAP. Nevertheless, it would be
> illuminating for me to hear your list of what SOAP has to offer REST.

Again, I think we need to separate REST and HTTP first. And establish that
HTTP is not the one answer to every question.

A good place to start that discussion is with Don Box's observations:
http://zdnet.com.com/2100-1105-845220.html

- Sam Ruby