web-services - 名称值对与 SOAP/WSDL 的优点

Question

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

Answer 1

在这个行业中，关于不同类型的 Web 服务似乎永无止境。

SOAP 是 消息协议(protocol) .它与 REST 的共同点就像苹果与草坪拖拉机的共同点一样。在消息传递协议(protocol)中你想要的一些东西是:

标题和其他非内容“属性”。

寻址 - 根据 header 将消息路由到不同的服务器/收件人；

通过排队等方式保证送达；

加密、签名和其他安全功能；

交易和编排；

在单个消息中准确表示复杂的结构化数据；

...等等。这不是一个详尽的 list 。 WSDL 添加到 SOAP 的主要内容是:

通过合约的可发现性，一种机器可读的“文档”形式，它告诉消费者发送消息需要什么，并允许自动生成代理；

严格的、自动化的消息模式验证，与 XSD 对 XML 的工作方式相同。

REST 是 不是 一种消息传递协议(protocol)。 REST 是一个系统 资源和 行动 .由于其他答案概述的几个重要原因，它是许多架构的可靠选择。它也与 PayPal 和 flickr 等“NVP”服务几乎没有相关性。

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

特别是在 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 格式下载它并将其绑定(bind)到类似 jqGrid 的东西。有趣的不是请求使用了“名称-值对”；有趣的是，它是一个简单的 URL，任何知道如何请求网页的人都可以使用它。

因此，为了尝试总结我所说的所有内容，请这样想:

当您希望将数据作为永久资源公开、使用或发布时，请使用 REST API(如果可用)。

当系统本质上是事务性的和/或当您需要复杂的消息传递协议(protocol)可以提供的高级功能(例如 RM 和寻址)时，请使用 SOAP API。

当没有 SOAP API 或无法使用 SOAP API 时，请使用 RPC API(几乎包括任何完全围绕 HTTP POST 建模的 API)。

希望能消除一些困惑。