It's unfortunate that we're still reading articles like this, where the
author has clearly not followed the discussion very closely at all, and
as a result, continues to perpetuate common misunderstandings which only
take away from the important technical aspects of the discussion.

More in-line ...

On Mon, Apr 04, 2005 at 03:16:29PM -0000, Gervas Douglas wrote:
> So what really is the difference between the two approaches, and which
> should you use? What SOAP has that REST doesn't, is a set of standard
> meta data about the message being sent. This meta data is intended to
> be used by Web service tools and infrastructure. In the REST example,
> the message sent during a Web service invocation only consists of the
> application-specific XML. However, using SOAP, that same Web service
> invocation would contain both the XML message but also a special
> header section where standard metadata about the message would be
> stored.

HTTP messages contain headers too;

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

> The SOAP vs. REST debate then should not be a discussion of WHICH, but
> rather, WHERE. Each has their place.

Now this, I largely agree with. IMO, the place for Web services is
behind the firewall, while the place for REST is both in front and
behind the firewall.

> REST is perfectly fine for simple
> request response exchanges between two partners, but once you start
> getting into enterprise level integration scenarios where you have
> multiple systems to integrate, security and choreography challenges to
> be aware of, SOAP is an essential standard that tools like integration
> servers, Enterprise Service Buses (ESBs), Business Process Management
> (BPM) systems and other integration solutions rely on.

Does the author have any technical evidence to back up the implicit
claim that REST is not suitable for use by those systems? State
transfer based styles (e.g. EDI) have been used for business integration
for many years.

Cheers,

Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca