名称值对对 SOAP/WSDL 的优势答案

【问题标题】：Advantages of Name Value Pairs to SOAP/WSDL名称值对对 SOAP/WSDL 的优势
【发布时间】：2010-01-13 21:00:03
【问题描述】：

我看到 PayPal 等 API 提供使用 NVP 或 SOAP/WSDL 调用他们的服务。在使用传统 Web 服务（无 WCF）的 .NET 环境（3.5）时，哪个更好，为什么？我知道 WSDL 允许您插入 API URL 并为您生成包装器。那么为什么公司还要提供 NVP 呢？

【问题讨论】：

标签： web-services rest soap wsdl asmx

【解决方案1】：

这个行业似乎对不同类型的 Web 服务存在永无止境的困惑。

SOAP 是一种消息传递协议。它与 REST 的共同点就像苹果与草坪拖拉机的共同点一样。您希望消息协议中的一些内容是：

标题和其他非内容“属性”。
寻址 - 根据标头将消息路由到不同的服务器/收件人；
通过排队和其他方式保证送达；
加密、签名和其他安全功能；
事务和编排；
在单个消息中准确表示复杂的结构化数据；

...等等。这不是一个详尽的清单。 WSDL 为 SOAP 添加的主要内容是：

通过合约的可发现性，这是一种机器可读的“文档”形式，可以准确地告诉消费者发送消息所需的内容，并允许自动生成代理；
对消息进行严格的自动架构验证，与 XSD 对 XML 的工作方式相同。

REST 不是一种消息传递协议。 REST 是一个由资源和动作组成的系统。出于其他答案所述的几个重要原因，对于许多架构来说，它是一个可靠的选择。它也与 PayPal 和 flickr 等“NVP”服务几乎没有关系。

PayPal 的 NVP API 不是 REST。对于不支持或难以支持 SOAP 的客户端，它是一种替代的、类似 RPC 的 HTTP POST 消息传递协议。这不是我的观点，这是事实陈述。 NVP 中的字段之一实际上是METHOD。这显然是 RPC 用语。看看他们的UpdateRecurringPaymentsProfile 的 API 并尝试告诉我，将其描述为“资源”是有道理的。这不是资源，而是操作。

就 PayPal 而言，“NVP”(HTTP POST) API 在几乎所有方面都不如 SOAP API。它适用于无法使用 SOAP 的消费者。如果你可以使用它，你肯定应该。

我也不一定为此抨击 PayPal。我知道很多人因为没有将“适当的” RESTful API 放在一起而抨击他们，但这不是我想要的。并非世界上的每一项服务都可以用 REST 准确描述。 PayPal 并不是真正的基于资源的系统，它是一个事务性 系统，所以我可以原谅他们的架构师和开发人员没有完美优雅的 REST 架构。这也许值得商榷，但不是非黑即白。没关系;如果需要，我将只使用 SOAP 系统。

将此与Twitter API 进行比较。这是一个真正的 REST 服务。您可以在此 API 上执行的每个“操作”都准确地描述为检索或提交特定类型的资源。资源是推文、状态、用户。在这种情况下，使用复杂的 SOAP API 从字面上看是没有意义的，因为您并没有真正发送消息，您没有执行事务，您只是在请求具体的事物，而这些事物可以用一个URL来描述。唯一的区别是，您获取的不是 HTML 网页，而是一些 XML 或 JSON 数据；你请求的方式完全一样。

REST Web 服务通常（总是？）使用 HTTP GET 来检索某些资源。而 Twitter 正是这样做的。 GET 仍然使用“名称-值对”——即查询字符串 ?q=twitterapi&show_user=true。 ? 之后的那些位是名称-值对。这是一个很好的例子，说明了为什么要在 SOAP 上使用 REST；您可以将其连接到 RSS 提要并获取流式更新。我可以把它变成 Firefox 中的实时书签。或者我可以以 JSON 格式下载它并将其绑定到 jqGrid 之类的东西上。有趣的不是请求使用“名称-值对”；有趣的是，它是一个简单的 URL，任何知道如何请求网页的人都可以使用它。

所以要尝试总结我所说的所有内容，请这样想：

当您想要将数据公开、使用或发布为永久资源时，请使用 REST API（如果可用）。
当系统本质上是事务性的和/或当您需要复杂消息传递协议可以提供的高级功能（例如 RM 和寻址）时，请使用 SOAP API。
在没有 SOAP API 或无法使用 SOAP API 时使用 RPC API（包括几乎所有完全围绕 HTTP POST 建模的 API）。

希望这能消除一些困惑。

【讨论】：

很好的解释/细节 - IMO 你的位置。

【解决方案2】：

我假设您所说的名称值对是指 REST 服务。

REST 的好处主要是易于开发、简单和优雅，以及较低的开销（如果您要发送和接收大量小消息，这一点非常重要）。

以下是 REST 的一些优点：

REST 更轻量级
人类可读的结果
一切都是 URI 可寻址资源
REST 服务更容易缓存
REST 更容易构建（不需要工具包）
REST 更容易调用（HTTP - GET、POST、PUT、DELETE）

【讨论】：

事情就是这样。我第一次使用 API（特别是 Facebook）时，我手动编写了所有包装器。我的老板来找我说你为什么要这样做，而你本来可以使用 WSDL！因为那样a）您无需手动编写任何包装器并且b）如果它们的API发生更改，您无需返回并更改所有包装器，因此c）您的应用程序不会在API上中断由供应商更改
@coffeeaddict 在很多方面你的老板都是对的。按照 Facebook API 的编写方式，您别无选择，只能创建封装类，以与 WSDL 客户端代理相同的方式耦合您。如果 Facebook API 实际上是 RESTful 的，那么耦合会显着减少，并且使用它比使用 WSDL 的好处会更加明显。
@Gabriel：特别提到的 PayPal API 使用编码后的 POST 正文（而不是 URI 或消息头）来包含详细信息，例如正在执行的资源、正在执行的操作（查询vs update) 和所有身份验证信息。 API 有一个用于所有请求的 URI。除了通过 HTTP 传输之外，它基本上没有 RESTful Web 服务的任何方面。
@Gabriel：在这种情况下，SOAP 也是 RESTful 的 :) 我想说的是 PayPal API 缺少的是：不同资源的不同 URI；使用 GET 进行查询，而不是 POST；在消息响应中返回 URI（可发现的 URI 空间）；并且（甚至可能）使用 HTTP 标头进行身份验证，而不是 POST 正文。
3) NVP 可以是异步的 - 是的，但从 .NET 2.0 开始，即使对于 SOAP WSDL，Web 服务周期也是异步的

【解决方案3】：

NVP 是 HTTP POST

name=fred
amount=100
code=403

等

这是任何 HTML 浏览器的默认格式，因此很容易实现将数据发送到 Web 服务

我认为这不是从 Web 服务接收数据的好格式吗？ JSON 或 XML 会更合适

没有人使用 VisualStudio，或者可以访问自动包装器生成器，或者想要使用这样的野兽

许多 Web 混搭都是用 Javascript 编码的，因此使用 HTTP POST 发送数据是最简单的方法。返回结果是标准的 HTML 响应代码（200、403、500 等）和/或一些 JSON

许多服务提供商提供多种 API 来满足所有客户的需求

【讨论】：