Re: Why REST is a better way to do Web Services
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
> 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
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
> > 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
> 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
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
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
and many other fine articles on the controversial topic of Web Services
Michael D. Kersey
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center