名称值对相对于 SOAP/WSDL 的优点

发布于 2024-08-17 23:01:21 字数 150 浏览 3 评论 0原文

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

傾城如夢未必闌珊 2024-08-24 23:01:21

在这个行业中，对于不同类型的网络服务似乎永远存在着混乱。

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

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

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

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

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

PayPal 的 NVP API 不是 REST。它是一种基于 HTTP POST 的类似 RPC 消息传递协议的替代方案，适用于不支持或难以支持 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。 ? 之后的那些位是名称-值对。这是一个很好的例子，说明了为什么您希望使用 REST over SOAP；您可以将其连接到 RSS 提要并获取流式更新。我可以将它变成 Firefox 中的实时书签。或者我可以以 JSON 格式下载它并将其绑定到 jqGrid 之类的东西。有趣的不是请求使用“名称-值对”；而是请求使用了“名称-值对”。有趣的是，它是一个简单的 URL，任何知道如何请求网页的人都可以使用它。

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

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

希望这能消除一些混乱。

There seems to be never-ending confusion in this industry about the different types of web services.

SOAP is a messaging protocol. It has as much in common with REST as an apple has with a lawn tractor. Some of the things you want in a messaging protocol are:

Headers and other non-content "attributes."
Addressing - routing of a message to different servers/recipients based on the headers;
Guaranteed delivery via queuing and other methods;
Encryption, signing, and other security features;
Transactions and orchestrations;
Accurate representation of complex structured data in a single message;

...and so on. This is not an exhaustive list. What WSDL adds to SOAP, primarily, is:

Discoverability via a contract, a form of machine-readable "documentation" that tells consumers exactly what is required in order to send a message and allows proxies to be auto-generated;
Strict, automated schema validation of messages, the same way XSD works for XML.

REST is not a messaging protocol. REST is a system of resources and actions. It is a solid choice for many architectures for several important reasons as outlined by other answers. It also has little to no relevance to "NVP" services like PayPal and flickr.

PayPal's NVP API is not REST. It is an alternative, RPC-like messaging protocol over HTTP POST for clients that don't support or have difficulty supporting SOAP. This isn't my opinion, it's a statement of fact. One of the fields in the NVP is actually METHOD. This is clearly RPC verbiage. Take a look at their API for UpdateRecurringPaymentsProfile and try to tell me that this makes a lick of sense to describe as a "resource". It's not a resource, it's an operation.

In the case of PayPal specifically, the "NVP" (HTTP POST) API is inferior to the SOAP API in almost every way. It is there for consumers who can't use SOAP. If you can use it, you definitely should.

And I'm not necessarily bashing PayPal for this, either. I know a lot of folks have bashed them for not putting together a "proper" RESTful API but that is not what I am getting at. Not every service in the world can be accurately described with REST. PayPal isn't really a resource-based system, it's a transactional system, so I can forgive their architects and developers for not having a perfectly elegant REST architecture. It's debatable perhaps, but it's not black-and-white. It's fine; I'll just use the SOAP system if I need to.

Compare this to, say, the Twitter API. This is a true REST service. Every "operation" you can perform on this API is accurately described as either the retrieval or submission of a particular kind of resource. A resource is a tweet, a status, a user. In this case it literally makes no sense to use a complex SOAP API because you're not really sending messages, you're not performing transactions, you're just asking for specific things, and these things can be described with a single URL. The only difference is that instead of getting an HTML web page back, you're getting some XML or JSON data; the way you request it is exactly the same.

A REST Web Service usually (always?) uses HTTP GET for the retrieval of some resource. And Twitter does exactly this. GET still uses "Name-Value Pairs" - that's the query string, ?q=twitterapi&show_user=true. Those bits after the ? are name-value pairs. And here's a great example of why you would want to use REST over SOAP; you can hook this up to an RSS feed and get streaming updates. I can turn it into a Live Bookmark in Firefox. Or I can download it in JSON format and bind it to something like a jqGrid. The interesting thing is not that the request uses "Name-Value Pairs"; the interesting thing is that it's a simple URL and can be consumed by anything that knows how to request a web page.

So to try and summarize all of what I've said, think of it this way:

Use a REST API (if available) when you want to expose data, or consume or publish it, as a permanent resource.
Use a SOAP API when the system is transactional in nature and/or when you need the advanced features that a complex messaging protocol can offer, such as RM and addressing.
Use an RPC API (which includes just about any API that's modeled entirely around HTTP POST) when there is no SOAP API or when you are unable to use the SOAP API.

Hope that clears up some of the confusion.

回复收藏 0 原文

怪异←思 2024-08-24 23:01:21

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

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

以下是 REST 的一些优点：

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

回复收藏 0 原文

帅气尐潴 2024-08-24 23:01:21

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 来满足所有客户的需求

NVP is HTTP POST

name=fred
amount=100
code=403

etc

This is the default format from any HTML browser so it's simple to implement for sending data to a web service

I don't think it's a good format for receiving data from web service? JSON or XML would be more suitable

No everyone uses VisualStudio, or has access to automatic wrapper generators, or wants to use such a beast

Many web mashups are coded in Javascript, so using HTTP POST to send data is the simplest way. The return result is a standard HTML response code (200, 403, 500, etc) and/or some JSON

Many service providers offer multiple API's to cater for all customers

回复收藏 0 原文

~没有更多了~