REST是进行Web服务的更好方法还是SOAP？还是针对不同问题的不同工具？还是一个微妙的问题，就是在某些领域中，一个领域比另一个领域中的问题要好一些，等等吗？

赏金编辑：

现在，将近三年后，我想再次提出这个问题，以提供赏金来鼓励深入的回答。我特别希望了解有关这些概念及其与PHP宇宙以及现代高端Web应用程序的关系的信息。

解决方案

回答

很细微。

如果我们需要让其他系统与服务接口，那么很多客户将对SOAP感到满意，这是由于合同，WSDL和SOAP标准具有"验证"层。

对于日常的系统调用，我认为当进行简单的HTML调用时，SOAP会产生很多不必要的开销。

回答

这是一个很好的问题...我不想让我们误入歧途，所以我和我们一样愿意接受其他人的回答。对我而言，这实际上要归结为开销成本以及API的用途。在创建客户端软件时，我更喜欢使用Web服务，但是我不喜欢SOAP的重量。我相信REST的重量较轻，但从客户的角度来看，我几乎不喜欢使用REST。

我对其他人的想法很好奇。

回答

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

回答

不要忽视XML-RPC。如果我们只想使用轻量级的解决方案，那么对于可以在几页文本中定义并以最少的代码实现的协议来说，有很多话要说。 XML-RPC已经存在了很多年，但是已经过时了一段时间，但是极简主义的吸引力似乎正在使它复兴。

回答

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

REST更简单，因此更易于维护，是Web体系结构的核心，允许更好的协议可见性，并且已经证明可以根据WWW本身的大小进行扩展。那里的一些框架可以构建REST服务，例如Ruby on Rails，甚至可以编写客户端，例如ADO.NET数据服务。但是在大多数情况下，缺少工具支持。

回答

REST是一种体系结构，SOAP是一种协议。

那是第一个问题。

我们可以在REST应用程序中发送SOAP信封。

SOAP本身实际上是非常基本和简单的，它之上的WSS- *标准使其变得非常复杂。

如果使用者是其他应用程序和其他服务器，那么今天对SOAP协议有很多支持，而移动数据的基础实质上是现代IDE中的鼠标单击。

如果使用者更可能是RIA或者Ajax客户端，则可能需要比SOAP更简单，更本地化的客户端(尤其是JSON)。

通过HTTP发送的JSON数据包不一定是REST架构，它只是发送到URL的消息。所有这些都可以很好地工作，但是REST惯用语包含一些关键组件。但是，很容易混淆两者。但是，仅仅因为我们在谈论HTTP请求，并不一定意味着我们拥有REST体系结构。我们可以拥有一个完全没有HTTP的REST应用程序(注意，这很少见)。

因此，如果服务器和使用者对SOAP感到"满意"，那么SOAP和WSS堆栈可以很好地为我们服务。如果我们正在做更多临时性的事情，并希望更好地与Web浏览器接口，那么一些通过HTTP的较轻协议也可以很好地工作。

回答

REST是与SOAP根本不同的范例。可以在这里找到关于REST的不错的阅读：我如何向妻子解释REST。

如果我们没有时间阅读它，这里是简短的版本：REST通过关注"名词"并限制可用于这些名词的"动词"的数量而在范式上有所转变。唯一允许使用的动词是" get"，" put"，" post"和" delete"。这与SOAP不同，SOAP可以将许多不同的动词应用于许多不同的名词(即，许多不同的功能)。

对于REST，这四个动词映射到相应的HTTP请求，而名词由URL标识。这使得状态管理比SOAP中的透明得多，后者通常不清楚服务器上的状态是什么，客户端上的状态是什么。

在实践中，尽管大多数情况都消失了，并且REST通常仅指的是以JSON返回结果的简单HTTP请求，而SOAP是通过传递XML进行通信的更为复杂的API。两者都有其优点和缺点，但是根据我的经验，REST通常是更好的选择，因为我们几乎不需要SOAP的全部功能。

回答

从工具的角度来看，SOAP很有用，因为WSDL很容易被工具使用。因此，我们可以使用自己喜欢的语言为我们生成Web Service客户端。

REST在AJAX的网页中表现良好。如果请求简单，则可以直接从JavaScript进行服务调用，这非常方便。尽量不要在响应XML中包含任何名称空间，我已经看到浏览器对此感到烦恼。因此，xsi：type可能对我们不起作用，也没有过于复杂的XML模式。

REST也往往具有更好的性能。生成REST响应的代码对CPU的要求往往低于SOAP框架所显示的要求。而且，如果我们在服务器端排列了XML生成鸭子，则可以有效地将XML流传输到客户端。因此，假设我们正在读取数据库游标的行。读取行时，将其格式化为XML元素，然后将其直接写出给服务使用者。这样，我们不必在开始编写同时读取和写入的XML输出之前就必须收集内存中的所有数据库行。研究新颖的模板引擎或者XSLT，以使流工作于REST。

另一方面，SOAP倾向于由工具生成的服务作为一个大对象来生成，然后才被编写。请注意，这不是一个绝对的事实，有很多方法可以通过使用SOAP来获得SOAP的流特征，例如通过使用附件。

我的决策过程如下：如果我希望消费者可以轻松地使用我的服务，并且我写的消息将是中小型的(10MB或者更小)，并且我不介意消耗一些额外的CPU在服务器上循环，我使用SOAP。如果我需要在Web浏览器上提供AJAX服务，或者需要传送内容，或者我的响应很大，我可以使用REST。

最后，围绕SOAP建立了许多很棒的标准，例如WS-Security和获取有状态的Web服务，如果使用正确的工具，则可以插入这些标准。这种东西确实有所作为，可以满足一些繁琐的要求。

回答

我确定Don Box开个玩笑是说SOAP，"看起来我们可以在网上调用RPC方法"，而今天，当他意识到Web标准已成为肿的噩梦时，他然大悟

REST是一种好，简单的方法，可快速，轻松地在任何地方实施(因此比标准更多的是"标准")。使用REST。

回答

当我在惠普工作时，我根据最初的规范构建了第一批SOAP服务器，包括代码生成和WSDL生成。我不建议对任何东西使用SOAP。

首字母缩写词" SOAP"是谎言。它不是简单的，不是面向对象的，它没有定义访问规则。可以说，它是一个协议。这是Don Box有史以来最糟糕的规格，这确实是一项壮举，因为他是实施" COM"的人。

在SOAP中，没有什么可以用REST进行传输，JSON，XML甚至纯文本进行数据表示的方法有用。为了传输安全，我们可以使用https。对于身份验证，请使用基本身份验证。对于会话，有cookie。 REST版本将更简单，更清晰，运行速度更快并且使用的带宽更少。

XML-RPC清楚地定义了请求，响应和错误协议，并且对于大多数语言都有不错的库。但是，XML比许多任务所需的重。

回答

如果我们使用Java，则建议我们先使用REST，再看看JAX-RS和Jersey的实现。 REST在许多语言中都非常简单且易于互操作。

就像其他人在该线程中所说的那样，SOAP的问题在于，当其他WS- *规范出现时，SOAP的复杂性；如果我们误入WSDL，XSD，SOAP，WS-Addressing等错误的部分，则会存在无数互操作问题。

判断REST v SOAP争论的最好方法是在Internet上浏览Web空间中的所有大型企业，Google，Amazon，ebay，Twitter等倾向于使用RESTful API，而不是SOAP API。

使用REST的另一种不错的方法是，我们可以在Web应用程序和REST前端之间重用大量代码和基础结构。例如使用JAX-RS和隐式视图之类的框架，通常可以非常轻松地呈现资源的HTML，XML和JSON，并且易于使用Web浏览器处理RESTful资源

回答

收听此播客以查找答案。如果我们想不听就知道答案，那么可以使用它的REST。但我确实建议我们收听。

回答

尚未提及的一件事是，SOAP信封可以包含标头以及主体部分。这使我们可以使用XML的完整表达能力来发送和接收带外信息。据我所知，REST将我们限制为HTTP标头和结果代码。

(otoh，我们可以将cookie与REST服务一起使用来发送"标头"类型的带外数据吗？)

回答

我编写的大多数应用程序是服务器端Cor Java，或者是WinForms或者WPF中的桌面应用程序。这些应用程序往往需要比REST可以提供的功能更丰富的服务API。另外，我不想花太多时间来创建我的Web服务客户端。 WSDL处理客户端生成工具使我能够实施客户端并继续增加业务价值。

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

如此说来，有一些javascript的SOAP客户端；我知道jQuery有一个。因此，可以从javascript中利用SOAP。只是不如返回JSON字符串的REST服务好。因此，如果我想要一个足够复杂的Web服务，使其对于任意数量的客户端技术和用途都具有灵活性，那么我将使用SOAP。

回答

我知道这是一个古老的问题，但是我必须发布答案，也许有人会觉得有用。我不敢相信有多少人推荐基于SOAP的REST。我只能假设这些人不是开发人员，或者从未真正实现任何合理规模的REST服务。实施REST服务要比实施SOAP服务花费很多时间。最后，它也变得更加混乱。这是我99％的时间选择SOAP的原因：

1)实现REST服务比实现SOAP服务花费的时间无限长。存在用于所有现代语言/框架/平台的工具，这些工具可以在WSDL中读取并输出代理类和客户端。 REST服务的实现是手工完成的，请阅读文档以获取此信息。此外，在实现这两项服务的同时，我们必须"猜测"由于没有真正的架构或者参考文档而将在管道中返回的内容。

2)为什么要编写仍返回XML的REST服务？唯一的区别是，使用REST，我们不知道每个元素/属性表示的类型都是我们自己实现的，并希望有一天不会在我们认为永远是int的字段中遇到字符串。 SOAP使用WSDL定义数据结构，因此这是理所当然的。

3)我听到有人抱怨说，使用SOAP可能会导致SOAP信封的"开销"。在这个时代，我们真的需要担心几个字节吗？

4)我听过这样的说法，使用REST，我们可以将URL弹出浏览器并查看数据。当然，如果REST服务使用的是简单身份验证或者不使用身份验证。例如，Netflix服务使用OAuth，它要求我们对事物进行签名和编码，然后才能提交请求。

5)为什么每个资源都需要一个"可读的" URL？如果我们使用工具来实现服务，那么我们真的关心实际的URL吗？

我需要继续吗？