不要忽视XML-RPC。如果您只是追求一个轻量级的解决方案，那么对于一个可以在几页文本中定义并在最少的代码中实现的协议来说，有很多事情要做。XML-RPC已经存在了多年，但已经过时了一段时间——但是极简主义的吸引力似乎使它在最近得到了某种复兴。

如果您正在寻找不同系统和语言之间的互操作性，我肯定会选择REST。例如，在尝试让SOAP在. net和Java之间工作时，我遇到了很多问题。

SOAP目前具有更好的工具的优势，它们可以为服务层生成大量样板代码，也可以从任何给定的WSDL生成客户端。

REST更简单，因此更容易维护，位于Web体系结构的核心，允许更好的协议可见性，并且已被证明可以扩展到WWW本身的大小。有些框架可以帮助您构建REST服务，如Ruby on Rails，有些甚至可以帮助您编写客户端，如ADO。NET数据服务。但在大多数情况下，缺乏工具支持。

我创建了一个基准，以找出它们中哪一个更快! 我看到了这样的结果:

对于1000个请求:

休息用时3秒 SOAP耗时7秒

对于10,000个请求:

休息用时33秒 SOAP用时69秒

对于1,000,000个请求:

休息用时62秒 SOAP耗时114秒

REST是Roy Fielding发明的一种架构，并在他的论文《架构风格和基于网络的软件架构设计》中进行了描述。Roy也是HTTP协议的主要作者，该协议定义了在万维网上的文档传输。HTTP是RESTful协议。当开发人员谈论“使用REST Web服务”时，可能更准确的说法是“使用HTTP”。

SOAP是一种基于xml的协议，它在HTTP请求/响应中进行隧道传输，因此即使您使用SOAP，您也在使用REST。关于SOAP是否为基本HTTP添加了任何重要的功能存在一些争论。

在创建Web服务之前，我建议学习HTTP。很可能您的需求可以使用规范中已经定义的功能实现，因此不需要其他协议。

我写的大多数应用程序都是服务器端c#或Java，或者WinForms或WPF中的桌面应用程序。这些应用程序往往需要比REST所能提供的更丰富的服务API。另外，我不想在创建web服务客户机上花费超过几分钟的时间。WSDL处理客户端生成工具允许我实现我的客户端并继续添加业务价值。

现在，如果我为一些javascript ajax调用显式地编写web服务，它可能是在REST中;只是为了了解客户端技术和利用JSON。在我看来，从javascript中使用的web服务api可能不应该非常复杂，因为这种类型的复杂性似乎可以更好地处理服务器端。

也就是说，javascript有一些SOAP客户端;我知道jQuery有一个。因此，SOAP可以从javascript中利用;只是不像REST服务返回JSON字符串那样好。因此，如果我有一个web服务，我希望它足够复杂，能够灵活地适应任意数量的客户端技术和用途，那么我会选择SOAP。