Re: Why REST is a better way to do Web Services

[Michael D. Kersey]

Notes inline...
David Bayley wrote:
> Michael D. Kersey wrote:
> > That's why REST is available today and easier to debug and develop
> > than the RPC approach. [...]
>
> You've got that the wrong way around. Yes HTTP is available today, but
> the reason that so many people are interested in Web Services are
> because HTTP doesn't cut it.

Nope, most currently plan to use Web Services by using SOAP-RPC,
effectively "tunneling" through HTTP. That is a non-RESTful method which
unduly clutters Web Services and raises all sorts of security and
communications problems.

> Web services however are
> promoting the WS-Security standards, that maintain independence from
> HTTP protocols. You're "may never" FUD, is clearly out of date.

The WS-Security standards are mostly IBM's and Microsoft's standards
formulated by the industry OASIS group.

The W3C working groups have no similar security standards yet nor do
they have a WS Security working group AFAIK.

In contrast, HTTPS and SSL are available and used today in a RESTful
fashion for RESTful Web Services.

> What about Transaction standards? Perhaps these should be munged into
> to the HTTP protocol as well. What about SMTP? Perhaps we should
> should just discard that rather important messaging protocol, and munge
> everything into HTTP headers?

Transaction processing has been discussed, but is a problem that has no
clear solution in a network on the scale of the internet. See the
(well-respected and widely read) paper by Waldo et al at
http://research.sun.com/techrep/1994/abstract-29.html
describing why you don't want to make certain things (e.g.,
transactions) transparent in a truly large-scale network. The paper
addresses the problems that restrict transaction processing in that
context: latency, concurrency, performance, partial failure and the lack
of a central resource manager.

> SOAP headers are a) independent of HTTP communication protocols, and b)
> extensible through XML formats. HTTP headers are like ASCII INI files
> in comparison.

Yes, and you can use SOAP with HTTP in a RESTful manner. It's SOAP-RPC
that Prescod et al object to.

> FWIW, I started with one of the other Prescod articles you posted. I
> found it far too abstract, and thought that this article presented the
> case for REST extremely well (at least as well as possible given the
> floored foundations). That was why I responded to it. If you can't
> defend a well written case for REST, then don't expect me to go hunting
> around all the other links you posted in search for an argument.

Why didn't you ask the author? I'm sure Prescod would be willing to hear
your objections and to address them.

BTW If you don't understand an article, don't blame me. Know that it's
not my responsibility to *make* you understand something, even were that
possible. You've been given an opportunity to learn something. Quit
being a whiner and engage your brain. See my earlier post today for *my*
*view* (not Prescod's) of some answers to your questions.

Finally if you don't have the patience to follow the W3C standards
bodies and to see what the state of the standards that you reference
truly is, then I must honestly ask why should anyone enter into a
discussion with you?

> > The true situation is that the W3C working groups on Web Services
> > (there are several) have been discussing REST for quite some time but
> > you and others haven't been listening. I suggest that you research
> > other links concerning REST, especially the the W3C working groups on
> > Web Services, to gain a better understanding of what you are missing.
> > Note that Prescod was originally *NOT* a supporter of REST, but once
> > he understood it, he became one of REST's most passionate proponents.
> > Some links:
>
> I've already given my arguments against REST, and presumably
> the rebel W3C community who agree with Prescod.

They are W3C working groups members, previous members and invited
experts. There is nothing "rebellious" about them. They are
well-reasoned people who read and understand the standards and who will
set new standards.

> It doesn't supplant anything, it is just a bog standard hack of HTTP,
> pushing it way beyond what it was designed for. And no, there is
> nothing "arbitrary" about programmer-defined methods.

RPC-SOAP methods *are* arbitrary, beginning with the naming of the
methods, the arguments etc. In contrast, REST has the established
methods of HTTP which, while small in number, appear to suffice in
handling all problems presented to date. REST *does* require a change in
approach however.

> > There is no RPC protocol in use in any system on the scale of the
> > internet. The only proven protocols on the internet of the scale
> > demanded by Web Services are HTTP and email. And as the links above
> > point out, and as discussed at W3C in the various Web Services working
> > groups, there are *no* examples whatsoever of large-scale deployments
> > of DCOM, CORBA or Java-RMI even remotely as large as those already
> > done using REST. RPC architectures have proven successful only under
> > very limited and controlled circumstances (e.g., within a single
> > corporation or between two or three corporations where the developers
> > could meet and coordinate software interfaces).
>
> This is absurd.
> Of course HTML content over HTTP has been extremely
> successful. Don't try to re-claim this success under the "REST" banner.

Sorry, but the current WWW *is* REST. You might read parts of Roy
Fielding's doctoral dissertation, wherein the term REST is coined.

Q. Why should you read it?
A. Because Fielding is one of the architects of the WWW. He helped
design and build it and he understands and explains how it works and why
it does work so well. Fielding's doctoral dissertation is
"Representational State Transfer: An Architectural Style for Distributed
Hypermedia Interaction" available at
http://www.ics.uci.edu/~fielding/tal...9805/index.htm

> This what I find most distasteful about your advocacy of REST. Web
> Services are not out to achieve the scale of deployment that ZDNet's
> "REST" HTML pages do.
> The B2B market for RPC services is obviously more limited in scale.

First I've heard of that!-))

> What sort of straw man are you building trying to
> compare compare Web Services with www.porn-r-us.com?

If you are interested in porn, this is the wrong newsgroup.

> > Security alone is a nightmare for RPC-SOAP Web Services: vendors are
> > proposing special Web Services firewalls that look *inside* the SOAP
> > envelope of each arriving Web Service request to determine whether it
> > should be accepted. Such a "Web Services firewall" must
> > 1) parse the SOAP envelope (an extremely compute-intensive operation)
> > and
> > 2) be programmed to recognize the particular RPC request as defined by
> > the Web Service developer.
> > What a nightmare! Certainly the hardware vendors are ready and willing
> > to sell such products since to do so would require that *every*
> > existing firewall be replaced by a "Web Services firewall"!
>
> I think you are looking at this the wrong way around. The indendence
> from HTTP provides an *extensible* security model. If you just want to
> stick with HTTP firewalls, then SOAP Web Services won't limit the
> ability of existing firewalls in any way.

AFAIK currently deployed firewalls cannot examine SOAP headers for
proper method calls. So if an application is not properly written or if
the programmer neglects the possibility of a buffer overflow attack,
then the Web Service becomes an open gateway into the system.

Of course the firewall vendors are working on ways to make new firewalls
that can peer into the SOAP envelope. You can buy one to replace each of
your (now supposedly defunct) firewalls!-))

BTW another downside of this situation is that whomever currently
configures firewalls will soon be responsible for SOAP firewall
configuration too.

But RESTful implementations of Web Services can be done today and on the
same firewalls you've used for years. There's no need to wait for a WS
security standard to be published or tools and special hardware to be
created that may/not adhere to those standards. All the standards
already exist and the firewall configuration is done in the same manner
it currently is.
Thisis because REST *is* the WWW.

> > I leave it to the market to decide.
> There is nothing to decide.

Did I hear "Ve haff our vays. Zere is nosing to deside!"? No thanks,
I'll leave it to the market.

> REST is just a further hacking of HTTP that
> has been hacked to death already.

Au contraire, REST is beautiful and simple and works today.

In stark contrast, RPC-SOAP Web Services are like the alien baby of the
movie "Alien Resurrection": generated automagically by an unknown
mechanism, complex, ugly to the eye, difficult to explain (especially
their existence), they are dangerous even to their own mothers (their
designers). SOAP-RPC Web Services are the true kludges of standards.

Q. But just how ugly are RPC-SOAP Web Services?
A. RPC-SOAP Web Services are so ugly that tools must be designed to hide
their ugliness, arcanity and inefficiency from the programmer.

Q. Who cares if they're ugly? They're still *my* babies! Waaahh!
A. You will care! As Waldo's paper above points out, when you hide the
presence of the network from the developer as is done with such tools,
you introduce problems that will not go away until you reveal that
ugliness. Sad thing is, RPC-SOAP is ugly enough to turn most
programmer's brains to stone; seems it's happened to some people on
these newsgroups already!-))

> Web Services are a proposal for
> consolidating the various RPC protocols that work on a completely
> different level. Web Services _wrap_ HTTP, as well as TCP/IP, SMTP, and
> any other communications protocol.

You've got it backwards: in outbound messages, the lower protocols wrap
the higher ones in envelopes and forward them to even lower protocols.
The process is reversed for inbound messages. HTTP is an "application"
level protocol - the highest level in the OSI 7-layer reference model.
There is no higher level.

See "Kicking out the Cuckoo" at
http://www.xml.com/pub/a/2002/04/24/taglines.html
which outlines briefly the genesis of RPC-SOAP Web Services, starting
with Microsoft marketing and ending with a discussion of the time wasted
by the W3C on standards for this ugly inefficient technology.

Also see "Web Services: It's so Crazy It Just Might Not Work" at
http://www.xml.com/pub/a/2001/10/03/webservices.html
and many other fine articles on the controversial topic of Web Services
at xml.com.

Good Luck,
Michael D. Kersey

[David Bayley]

Michael D. Kersey wrote:

>> You've got that the wrong way around. Yes HTTP is available today,
>> but the reason that so many people are interested in Web Services are
>> because HTTP doesn't cut it.
>
> Nope, most currently plan to use Web Services by using SOAP-RPC,

I thought that was what I just said?

> effectively "tunneling" through HTTP. That is a non-RESTful method
> which unduly clutters Web Services and raises all sorts of security
> and communications problems.

Actually, it is the RESTafarians that are trying to unduly clutter Web
Services with HTTP, when the original charter was to be independent of
HTTP. After reading some more, I see that SOAP 1.2 has made some
compromises in order to support simple HTTP-GET access.

The wonders of design-by-committee!!!

> The WS-Security standards are mostly IBM's and Microsoft's standards
> formulated by the industry OASIS group.

Fair point. I think time is of the essence here, and standards groups
move too slowly. Hopefully the de-facto standards will make their way
into WC3.

> In contrast, HTTPS and SSL are available and used today in a RESTful
> fashion for RESTful Web Services.

Yes, HTTP is available today, but this is not a valid argument against
SOAP. Nothing happens overnight, even if you have to extend standards
(WS-Security) to get things moving.

> Transaction processing has been discussed, but is a problem that has
> no clear solution in a network on the scale of the internet. See the
> (well-respected and widely read) paper by Waldo et al at
> http://research.sun.com/techrep/1994/abstract-29.html
> describing why you don't want to make certain things (e.g.,
> transactions) transparent in a truly large-scale network. The paper
> addresses the problems that restrict transaction processing in that
> context: latency, concurrency, performance, partial failure and the
> lack of a central resource manager.

1994?!? Regardless, references to the "scale of the internet" is
loosely bandied about by the RESTafarians, and I've yet to see the
relevance of that argument.

If company ACME in the USA, wants to expose a Web Service to company X
in the UK, company Y in Germany, and company Z in Siberia, then this is
a scaling problem that has already been solved with TCP/IP and DNS.

Web Services aren't attempting to solve the same scalability problems
that Web Pages like those of Google or Yahoo do.

> Why didn't you ask the author? I'm sure Prescod would be willing to
> hear your objections and to address them.

Sorry, have lived in the luxury of NNTP discussions forums, so I can't
bear mailing lists, and even the RESTful web interfaces for viewing them
are painful. ;^)

I could see Web Services (the RPC kind) providing a perfectly good
substitute to NNTP. Browser UI servers could dyanmically transform the
XML messages into browser clients, and Fit UIs could handle the XML
messages statefully in rich clients.

> BTW If you don't understand an article, don't blame me. Know that it's
> not my responsibility to *make* you understand something, even were
> that possible. You've been given an opportunity to learn something.
> Quit being a whiner and engage your brain. See my earlier post today
> for *my* *view* (not Prescod's) of some answers to your questions.

Watch it bozo! ;-) You were "whining" that I had only read one of the
many links you posted. I merely pointed out, for what it was worth,
that the first link I read was too abstract. The second one clarified
the issue very well IMO, and since I disagreed with many of the
premises, clarified why the first abstract one was useless.

> Finally if you don't have the patience to follow the W3C standards
> bodies and to see what the state of the standards that you reference
> truly is, then I must honestly ask why should anyone enter into a
> discussion with you?

Err, to clear up this issue...

1) It is the REST community that are disrupting the W3C Web Service
standards. They may have a good case, but the debates are *live*.

2) /You/ raised the issue of REST. I am merely defending the status
quo of released SOAP/WSDL (aka Web Service) standards.

3) I spent some time understanding the REST links you posted, and
responded with what, I am confident, are some valid points.

The ball was well and firmly in your court, and I'm glad you finally
returned. But please, no more links, you've provided more than enough
for a healthy discussion.

[ This is dotnet.discussion so we can agree extremely viscously, with no
worries about having to produce a standard at the end of it all. :-) ]

> They are W3C working groups members, previous members and invited
> experts. There is nothing "rebellious" about them. They are
> well-reasoned people who read and understand the standards and who
> will set new standards.

Well, after reading the sales pitch, I went to W3C's ws-arch discussion
forum to get a more balanced picture, and I still think that
"rebellious" is the right term to use. I certainly don't use it
negatively, since it is often positive. The implication is that it is
fighting against accepted wisdom.

> RPC-SOAP methods *are* arbitrary, beginning with the naming of the
> methods, the arguments etc. In contrast, REST has the established
> methods of HTTP which, while small in number, appear to suffice in
> handling all problems presented to date. REST *does* require a change
> in approach however.

I agree that the SOAP/WSDL approach is different, but it it *less*
arbitrary. It is the very arbitrary/generic nature of URI resources, as
opposed to the defined/specific nature of WSDL services, that
RESTafarians appear to be advocating AFAICT.

> Sorry, but the current WWW *is* REST. You might read parts of Roy
> Fielding's doctoral dissertation, wherein the term REST is coined.

Yes, we are in viscous agreement here.

>> This what I find most distasteful about your advocacy of REST. Web
>> Services are not out to achieve the scale of deployment that ZDNet's
>> "REST" HTML pages do.
>> The B2B market for RPC services is obviously more limited in scale.
>
> First I've heard of that!-))

This is something I've always assumed, but I see the folks on ws-arch
are coming to the same conclusion (June/July archives). B2C
opportunities, are inherently far larger in scale than than B2B
opportunities. B2B links are limited to business partnerships. Also,
computers/businesses need defined contracts in order to communicate,
whereas consumers are orders of magnitude more flexible/intelligent.

The "Web" and "Scalability" are orthogonal concepts.

> AFAIK currently deployed firewalls cannot examine SOAP headers for
> proper method calls. So if an application is not properly written or
> if the programmer neglects the possibility of a buffer overflow
> attack, then the Web Service becomes an open gateway into the system.
>
> Of course the firewall vendors are working on ways to make new
> firewalls that can peer into the SOAP envelope. You can buy one to
> replace each of your (now supposedly defunct) firewalls!-))

Yes a valid, albeit transitional point. This boils down to the
"protocol independence" argument, and firewall vendors will need to
adapt like everyone else. The advantage though, is that SOAP headers
are XML based, and so more expressive than HTTP and port numbers.

> But RESTful implementations of Web Services can be done today and on
> the same firewalls you've used for years. There's no need to wait for
> a WS security standard to be published or tools and special hardware
> to be created that may/not adhere to those standards. All the
> standards already exist and the firewall configuration is done in the
> same manner it currently is.

The "no need to wait" argument has never prevented the progression of
more sophisticated technology, but it can delay it.

> Did I hear "Ve haff our vays. Zere is nosing to deside!"? No thanks,
> I'll leave it to the market.

Oops, sorry... No, that is not what I meant. Everything businesses need
for the RESTful architecture is here today, and in fact yester-year, in
the shape of HTTP/XML.

There is nothing to decide, because despite the availablitity of RESTful
standards, it hasn't been adopted. Instead, business are looking to the
higher level abstraction of Web Services (SOAP/WSDL).

--
David

[Michael D. Kersey]

Notes inline...
David Bayley wrote:
> Actually, it is the RESTafarians that are trying to unduly clutter Web
> Services with HTTP, when the original charter was to be independent of
> HTTP. After reading some more, I see that SOAP 1.2 has made some
> compromises in order to support simple HTTP-GET access.
> The wonders of design-by-committee!!!

Yes, indeed, the GET was something that REST supporters requested and
got, so that Web Services would remain compatible with the existing WWW
design.

> > See the
> > (well-respected and widely read) paper by Waldo et al at
> > http://research.sun.com/techrep/1994/abstract-29.html
> > describing why you don't want to make certain things (e.g.,
> > transactions) transparent in a truly large-scale network. The paper
> > addresses the problems that restrict transaction processing in that
> > context: latency, concurrency, performance, partial failure and the
> > lack of a central resource manager.
>
> 1994?!?

It was a good year?-)) But really now, good research done anytime is
still good. The theory of relativity was conceived of in the early
1900's and is still good. The Waldo paper is interesting, although
somewhat of a downer for me.

> Regardless, references to the "scale of the internet" is
> loosely bandied about by the RESTafarians, and I've yet to see the
> relevance of that argument.

I think the relevance was largely hidden from us, since the very people
who architected the WWW during it's period of greatest growth were very
busy then, but were the same people who later explicated their
architecture as REST.

> If company ACME in the USA, wants to expose a Web Service to company X
> in the UK, company Y in Germany, and company Z in Siberia, then this is
> a scaling problem that has already been solved with TCP/IP and DNS.
>
> Web Services aren't attempting to solve the same scalability problems
> that Web Pages like those of Google or Yahoo do.

This is undoubtedly true, especially early in the adoption process. But
later when your firm merges with another and your boss tells you to
extend those Web Services formerly used by 12 clients to another 10,000,
something may hit the fan!

> > Why didn't you ask the author? I'm sure Prescod would be willing to
> > hear your objections and to address them.
>
> Sorry, have lived in the luxury of NNTP discussions forums, so I can't
> bear mailing lists, and even the RESTful web interfaces for viewing them
> are painful. ;^)

Ha! And I couldn't agree more. But I have met surprising resistance
(perhaps "inertia" would be a better term) when introducing NNTP into
corporate environments. I am constantly amazed that individuals who have
no trouble with email can be paralyzed by a newsgroup. Newsgroups are an
incredible collaborative tool and IMO greatly underutilized.

> I could see Web Services (the RPC kind) providing a perfectly good
> substitute to NNTP. Browser UI servers could dyanmically transform the
> XML messages into browser clients, and Fit UIs could handle the XML
> messages statefully in rich clients.

These are several very good ideas, since those people who are so wary of
NNTP are fearless before a WWW interface.

> > BTW If you don't understand an article, don't blame me. Know that it's
> > not my responsibility to *make* you understand something, even were
> > that possible. You've been given an opportunity to learn something.
> > Quit being a whiner and engage your brain. See my earlier post today
> > for *my* *view* (not Prescod's) of some answers to your questions.
>
> Watch it bozo! ;-) You were "whining" that I had only read one of the
> many links you posted. I merely pointed out, for what it was worth,
> that the first link I read was too abstract. The second one clarified
> the issue very well IMO, and since I disagreed with many of the
> premises, clarified why the first abstract one was useless.
>
> > Finally if you don't have the patience to follow the W3C standards
> > bodies and to see what the state of the standards that you reference
> > truly is, then I must honestly ask why should anyone enter into a
> > discussion with you?
>
> Err, to clear up this issue...
>
> 1) It is the REST community that are disrupting the W3C Web Service
> standards. They may have a good case, but the debates are *live*.

They're part of the standards process and they've brought a great deal
to the standards.

> 2) /You/ raised the issue of REST. I am merely defending the status
> quo of released SOAP/WSDL (aka Web Service) standards.
>
> 3) I spent some time understanding the REST links you posted, and
> responded with what, I am confident, are some valid points.
>
> The ball was well and firmly in your court, and I'm glad you finally
> returned. But please, no more links, you've provided more than enough
> for a healthy discussion.
>
> [ This is dotnet.discussion so we can agree extremely viscously, with no
> worries about having to produce a standard at the end of it all. :-) ]

Well, you're spot-on on these points, and I feel like a troll. Think
I'll go crawl under a bridge somewhere and sulk after writing this. My
apologies: sometimes even trolls get excited about ideas.

> > They are W3C working groups members, previous members and invited
> > experts. There is nothing "rebellious" about them. They are
> > well-reasoned people who read and understand the standards and who
> > will set new standards.
>
> Well, after reading the sales pitch, I went to W3C's ws-arch discussion
> forum to get a more balanced picture, and I still think that
> "rebellious" is the right term to use. I certainly don't use it
> negatively, since it is often positive. The implication is that it is
> fighting against accepted wisdom.
>
> > RPC-SOAP methods *are* arbitrary, beginning with the naming of the
> > methods, the arguments etc. In contrast, REST has the established
> > methods of HTTP which, while small in number, appear to suffice in
> > handling all problems presented to date. REST *does* require a change
> > in approach however.
>
> I agree that the SOAP/WSDL approach is different, but it it *less*
> arbitrary. It is the very arbitrary/generic nature of URI resources, as
> opposed to the defined/specific nature of WSDL services, that
> RESTafarians appear to be advocating AFAICT.

But while a URI can be arbitrary, it is *exposed* and available on the
WWW. You can cut and paste it, write it on an envelope and mail it. You
can examine it's contents with a browser. Everything required in
processing is exposed.

And REST's limited set of methods (GET, POST, PUT, DELETE) simplifies
the publication and coordination of interfaces. Everyone knows how to
GET a URI, and POSTing XML to another URI is also straightforward (PUT
and DELETE are usually hidden, but IMO are easily explained and don't
have the nuances of GET and POST in the REST context).

IMO the difficult part of REST is the idea that the various URIs that
exist or may be created in an application or Web Service are actually
the states of a giant web-based virtual state machine, and that, as
operations are performed the application or Web Service moves from one
state(URI) to another.

The bad news is that AFAICT the REST style isn't object-oriented in the
usual sense. In contrast, SOAP-RPC has evolved from a design perspective
that is totally traditional OOP. So I'm not surprised that REST met
resistance not only for it's surprising and possibly unwelcome late
emergence (something like the swamp monster during a trout-fishing
tournament) but also because REST's implementation doesn't square with
the OOP paradigm that developers have been trying to use the last
decade.

The good news is that REST is extremely scaleable and robust because
- state is captured in the URIs,
- because URIs can be cached for performance, and
- because it requires no changes from the existing WWW and supporting
network (the Internet and it's hardware) to implement.

> > Sorry, but the current WWW *is* REST. You might read parts of Roy
> > Fielding's doctoral dissertation, wherein the term REST is coined.
>
> Yes, we are in viscous agreement here.
>
> >> This what I find most distasteful about your advocacy of REST. Web
> >> Services are not out to achieve the scale of deployment that ZDNet's
> >> "REST" HTML pages do.
> >> The B2B market for RPC services is obviously more limited in scale.
> >
> > First I've heard of that!-))
>
> This is something I've always assumed, but I see the folks on ws-arch
> are coming to the same conclusion (June/July archives). B2C
> opportunities, are inherently far larger in scale than than B2B
> opportunities. B2B links are limited to business partnerships. Also,
> computers/businesses need defined contracts in order to communicate,
> whereas consumers are orders of magnitude more flexible/intelligent.

This is no doubt true. but...

> The "Web" and "Scalability" are orthogonal concepts.
We disagree here: IMO the WWW is eminently scalable due to the RESTful
architecture. And violating the architectural constraints of REST will
reduce the scalability of an application or Web Service.

> > AFAIK currently deployed firewalls cannot examine SOAP headers for
> > proper method calls. So if an application is not properly written or
> > if the programmer neglects the possibility of a buffer overflow
> > attack, then the Web Service becomes an open gateway into the system.
> >
> > Of course the firewall vendors are working on ways to make new
> > firewalls that can peer into the SOAP envelope. You can buy one to
> > replace each of your (now supposedly defunct) firewalls!-))
>
> Yes a valid, albeit transitional point. This boils down to the
> "protocol independence" argument, and firewall vendors will need to
> adapt like everyone else. The advantage though, is that SOAP headers
> are XML based, and so more expressive than HTTP and port numbers.

Certainly SOAP headers are more expressive than HTTP headers. But
HTTP+XML is RESTful and should more than suffice.

I am surprised that the W3C working groups have not recommended that Web
Services exist on a port or ports separate from those currently reserved
for WWW HTTP(S)(80 and 443). On concern I have is that problematic Web
Services activity may interfere with a previously perfectly functioning
WWW. A more paranoid perspective is that this will happen *by design*.

> > But RESTful implementations of Web Services can be done today and on
> > the same firewalls you've used for years. There's no need to wait for
> > a WS security standard to be published or tools and special hardware
> > to be created that may/not adhere to those standards. All the
> > standards already exist and the firewall configuration is done in the
> > same manner it currently is.
>
> The "no need to wait" argument has never prevented the progression of
> more sophisticated technology, but it can delay it.
>
> > Did I hear "Ve haff our vays. Zere is nosing to deside!"? No thanks,
> > I'll leave it to the market.
>
> Oops, sorry... No, that is not what I meant. Everything businesses need
> for the RESTful architecture is here today, and in fact yester-year, in
> the shape of HTTP/XML.
>
> There is nothing to decide, because despite the availablitity of RESTful
> standards, it hasn't been adopted. Instead, business are looking to the
> higher level abstraction of Web Services (SOAP/WSDL).
> --
> David

The inclusion of GET in the SOAP specification allows RESTful Web
Services to be part of the standards. But certainly it appears today
that most businesses who are rushing at all, are rushing to RPC-SOAP.
Whether they drown in the swamp or are saved by the swamp monster is a
matter for a later day.

Good Luck,
Michael D. Kersey