xml Web 服务是 SOAP 还是 REST？

SOAP or REST for Web Services?

提问by user13276

Is REST a better approach to doing Web Services or is SOAP? Or are they different tools for different problems? Or is it a nuanced issue - that is, is one slightly better in certain arenas than another, etc?

REST 是一种更好的 Web 服务方法还是 SOAP？或者它们是针对不同问题的不同工具？或者这是一个微妙的问题——也就是说，在某些领域中，某个领域是否比其他领域稍好一些，等等？

I would especially appreciate information about those concepts and their relation to the PHP-universe and also modern high-end web-applications.

我特别感谢有关这些概念及其与 PHP 世界以及现代高端 Web 应用程序的关系的信息。

回答by mdhughes

I built one of the first SOAP servers, including code generation and WSDL generation, from the original spec as it was being developed, when I was working at Hewlett-Packard. I do NOT recommend using SOAP for anything.

当我在 Hewlett-Packard 工作时，我根据正在开发的原始规范构建了第一个 SOAP 服务器，包括代码生成和 WSDL 生成。我不建议将 SOAP 用于任何事情。

The acronym "SOAP" is a lie. It is not Simple, it is not Object-oriented, it defines no Access rules. It is, arguably, a Protocol. It is Don Box's worst spec ever, and that's quite a feat, as he's the man who perpetrated "COM".

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

There is nothing useful in SOAP that can't be done with REST for transport, and JSON, XML, or even plain text for data representation. For transport security, you can use https. For authentication, basic auth. For sessions, there's cookies. The REST version will be simpler, clearer, run faster, and use less bandwidth.

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

XML-RPC clearly defines the request, response, and error protocols, and there are good libraries for most languages. However, XML is heavier than you need for many tasks.

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

回答by Will Hartung

REST is an architecture, SOAP is a protocol.

REST 是一种架构，SOAP 是一种协议。

That's the first problem.

这是第一个问题。

You can send SOAP envelopes in a REST application.

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

SOAP itself is actually pretty basic and simple, it's the WSS-* standards on top of it that make it very complex.

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

If your consumers are other applications and other servers, there's a lot of support for the SOAP protocol today, and the basics of moving data is essentially a mouse-click in modern IDEs.

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

If your consumers are more likely to be RIAs or Ajax clients, you will probably want something simpler than SOAP, and more native to the client (notably JSON).

如果您的消费者更有可能是 RIA 或 Ajax 客户端，您可能需要比 SOAP 更简单、更适合客户端（特别是 JSON）的东西。

JSON packets sent over HTTP is not necessarily a REST architecture, it's just messages to URLs. All perfectly workable, but there are key components to the REST idiom. It is easy to confuse the two however. But just because you're talking HTTP requests does not necessarily mean you have a REST architecture. You can have a REST application with no HTTP at all (mind, this is rare).

通过 HTTP 发送的 JSON 数据包不一定是 REST 架构，它只是到 URL 的消息。所有这些都完全可行，但 REST 习语有一些关键组件。然而，很容易将两者混淆。但仅仅因为您在谈论 HTTP 请求并不一定意味着您拥有 REST 架构。您可以拥有一个完全没有 HTTP 的 REST 应用程序（请注意，这很少见）。

So, if you have servers and consumers that are "comfortable" with SOAP, SOAP and WSS stack can serve you well. If you're doing more ad hoc things and want to better interface with web browsers, then some lighter protocol over HTTP can work well also.

因此，如果您的服务器和消费者对 SOAP“感到满意”，那么 SOAP 和 WSS 堆栈可以很好地为您服务。如果您正在做更多特别的事情并希望更好地与 Web 浏览器交互，那么一些基于 HTTP 的轻量级协议也可以很好地工作。

回答by toluju

REST is a fundamentally different paradigm from SOAP. A good read on REST can be found here: How I explained REST to my wife.

REST 是一种与 SOAP 完全不同的范式。可以在此处找到有关 REST 的好读物：我如何向我的妻子解释 REST。

If you don't have time to read it, here's the short version: REST is a bit of a paradigm shift by focusing on "nouns", and restraining the number of "verbs" you can apply to those nouns. The only allowed verbs are "get", "put", "post" and "delete". This differs from SOAP where many different verbs can be applied to many different nouns (i.e. many different functions).

如果您没有时间阅读它，这里有一个简短的版本：REST 是一种范式转变，它专注于“名词”，并限制了可以应用于这些名词的“动词”的数量。唯一允许的动词是“get”、“put”、“post”和“delete”。这与 SOAP 不同，SOAP 可以将许多不同的动词应用于许多不同的名词（即许多不同的功能）。

For REST, the four verbs map to the corresponding HTTP requests, while the nouns are identified by URLs. This makes state management much more transparent than in SOAP, where its often unclear what state is on the server and what is on the client.

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

In practice though most of this falls away, and REST usually just refers to simple HTTP requests that return results in JSON, while SOAP is a more complex API that communicates by passing XML around. Both have their advantages and disadvantages, but I've found that in my experience REST is usually the better choice because you rarely if ever need the full functionality you get from SOAP.

在实践中，虽然大部分都消失了，REST 通常只是指以JSON 形式返回结果的简单 HTTP 请求，而 SOAP 是一个更复杂的 API，它通过传递 XML 进行通信。两者都有其优点和缺点，但我发现根据我的经验，REST 通常是更好的选择，因为您很少需要从 SOAP 获得的完整功能。

回答by PmanAce

Quick lowdown for 2012 question:

2012 年问题的快速调查：

Areas that REST works really well for are:

REST 非常适合的领域是：

• Limited bandwidth and resources.Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard?GET,?PUT,?POST, and?DELETE?verbs. Again, remember that REST can also use the?XMLHttpRequest?object that most modern browsers support today, which adds an extra bonus of AJAX.

• Totally stateless operations.?If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.

• Caching situations.?If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.That covers a lot of solutions in the above three.

• 有限的带宽和资源。请记住，返回结构实际上是任何格式（由开发人员定义）。此外，任何浏览器都可以使用，因为 REST 方法使用标准的?GET、?PUT、?POST 和?DELETE?动词。再次记住，REST 也可以使用当今大多数现代浏览器支持的 XMLHttpRequest 对象，这增加了 AJAX 的额外好处。

• 完全无状态的操作。?如果操作需要继续，那么 REST 不是最好的方法，SOAP 可能更适合它。但是，如果您需要无状态 CRUD（创建、读取、更新和删除）操作，那么 REST 就是它。

• 缓存情况。?如果因为REST方式的完全无状态操作，可以缓存信息，那就完美了。这涵盖了上面三个中的很多解决方案。

So why would I even consider SOAP? Again, SOAP is fairly mature and well-defined and does come with a complete specification. The REST approach is just that, an approach and is wide open for development, so if you have the following then SOAP is a great solution:

那我为什么还要考虑 SOAP？同样，SOAP 相当成熟且定义良好，并且确实带有完整的规范。REST 方法就是这样，一种方法并且对开发开放，所以如果您有以下内容，那么 SOAP 是一个很好的解决方案：

• Asynchronous processing and invocation.?If your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.

• Formal contracts.?If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.

• Stateful operations.If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

• 异步处理和调用。?如果您的应用程序需要保证级别的可靠性和安全性，那么 SOAP 1.2 提供了额外的标准来确保此类操作。像 WSRM – WS-Reliable Messaging 这样的东西。

• 正式合同。?如果双方（提供者和消费者）必须就交换格式达成一致，那么 SOAP 1.2 为这种类型的交互提供了严格的规范。

• 有状态的操作。如果应用程序需要上下文信息和对话状态管理，那么 SOAP 1.2 在 WS* 结构中有额外的规范来支持这些事情（安全、事务、协调等）。相比之下，REST 方法将使开发人员构建这种自定义管道。

http://www.infoq.com/articles/rest-soap-when-to-use-each

http://www.infoq.com/articles/rest-soap-when-to-use-each

回答by Mark Cidade

SOAPcurrently has the advantage of better tools where they will generate a lot of the boilerplate code for both the service layer as well as generating clients from any given WSDL.

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

RESTis simpler, can be easier to maintain as a result, lies at the heart of Web architecture, allows for better protocol visibility, and has been proven to scale at the size of the WWW itself. Some frameworks out there help you build REST services, like Ruby on Rails, and some even help you with writing clients, like ADO.NET Data Services. But for the most part, tool support is lacking.

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

回答by Mark Cidade

SOAP is useful from a tooling perspective because the WSDL is so easily consumed by tools. So, you can get Web Service clients generated for you in your favorite language.

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

REST plays well with AJAX'y web pages. If you keep your requests simple, you can make service calls directly from your JavaScript, and that comes in very handy. Try to stay away from having any namespaces in your response XML, I've seen browsers choke on those. So, xsi:type is probably not going to work for you, no overly complex XML Schemas.

REST 与 AJAX'y 网页配合得很好。如果您保持请求简单，您可以直接从您的 JavaScript 进行服务调用，这非常方便。尽量避免在您的响应 XML 中包含任何名称空间，我已经看到浏览器被这些名称所困扰。所以， xsi:type 可能不适合你，没有过于复杂的 XML 模式。

REST tends to have better performance as well. CPU requirements of the code generating REST responses tend to be lower than what SOAP frameworks exhibit. And, if you have your XML generation ducks lined up on the server side, you can effectively stream XML out to the client. So, imagine you're reading rows of database cursor. As you read a row, you format it as an XML element, and you write that directly out to the service consumer. This way, you don't have to collect all of the database rows in memory before starting to write your XML output - you read and write at the same time. Look into novel templating engines or XSLT to get the streaming to work for REST.

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

SOAP on the other hand tends to get generated by tool-generated services as a big blob and only then written. This is not an absolute truth, mind you, there are ways to get streaming characteristics out of SOAP, like by using attachments.

另一方面，SOAP 往往由工具生成的服务生成为一个大 blob，然后才写入。请注意，这不是绝对真理，有一些方法可以从 SOAP 中获取流特性，例如使用附件。

My decision making process is as follows: if I want my service to be easily tooled by consumers, and the messages I write will be medium-to-small-ish (10MB or less), and I don't mind burning some extra CPU cycles on the server, I go with SOAP. If I need to serve to AJAX on web browsers, or I need the thing to stream, or my responses are gigantic, I go REST.

我的决策过程是这样的：如果我想让我的服务被消费者轻松地使用，我写的消息是中到小（10MB 或更少），我不介意消耗一些额外的 CPU在服务器上循环，我使用 SOAP。如果我需要在 Web 浏览器上为 AJAX 提供服务，或者我需要流式传输内容，或者我的响应很大，我会使用 REST。

Finally, there are lots of great standards built up around SOAP, like WS-Security and getting stateful Web Services, that you can plug in to if you're using the right tools. That kind of stuff really makes a difference, and can help you satisfy some hairy requirements.

最后，围绕 SOAP 建立了许多很棒的标准，例如 WS-Security 和获取有状态的 Web 服务，如果您使用正确的工具，您可以插入这些标准。这种东西真的很重要，可以帮助你满足一些毛茸茸的要求。

回答by Josh M.

I know this is an old question but I have to post my answer - maybe someone will find it useful. I can't believe how many people are recommending REST over SOAP. I can only assume these people are not developers or have never actually implemented a REST service of any reasonable size. Implementing a REST service takes a LOT longer than implementing a SOAP service. And in the end it comes out a lot messier, too. Here are the reasons I would choose SOAP 99% of the time:

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

1) Implementing a REST service takes infinitely longer than implementing a SOAP service. Tools exist for all modern languages/frameworks/platforms to read in a WSDL and output proxy classes and clients. Implementing a REST service is done by hand and - get this - by reading documentation. Furthermore, while implementing these two services, you have to make "guesses" as to what will come back across the pipe as there is no real schema or reference document.

1) 实现 REST 服务比实现 SOAP 服务花费的时间无限长。所有现代语言/框架/平台都有用于读取 WSDL 并输出代理类和客户端的工具。实现 REST 服务是手工完成的，并且通过阅读文档来获得它。此外，在实现这两个服务时，您必须“猜测”什么会通过管道返回，因为没有真正的模式或参考文档。

2) Why write a REST service that returns XML anyway? The only difference is that with REST you don't know the types each element/attribute represents - you are on your own to implement it and hope that one day a string doesn't come across in a field you thought was always an int. SOAP defines the data structure using the WSDL so this is a no-brainer.

2) 为什么要编写一个返回 XML 的 REST 服务？唯一的区别是，在 REST 中，您不知道每个元素/属性代表的类型 - 您需要自己实现它，并希望有一天字符串不会出现在您认为始终是 int 的字段中。SOAP 使用 WSDL 定义数据结构，因此这很简单。

3) I've heard the complaint that with SOAP you have the "overhead" of the SOAP Envelope. In this day and age, do we really need to worry about a handful of bytes?

3) 我听说有人抱怨使用 SOAP 会产生 SOAP Envelope 的“开销”。在这个时代，我们真的需要担心少量字节吗？

4) I've heard the argument that with REST you can just pop the URL into the browser and see the data. Sure, if your REST service is using simple or no authentication. The Netflix service, for instance, uses OAuth which requires you to sign things and encode things before you can even submit your request.

4) 我听说过这样的论点，即使用 REST，您只需将 URL 弹出到浏览器中即可查看数据。当然，如果您的 REST 服务使用简单身份验证或不使用身份验证。例如，Netflix 服务使用 OAuth，它要求您在提交请求之前对事物进行签名和编码。

5) Why do we need a "readable" URL for each resource? If we were using a tool to implement the service, do we really care about the actual URL?

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

Need I go on?

需要我继续吗？

回答by Travis Heseman

Most of the applications I write are server-side C# or Java, or desktop applications in WinForms or WPF. These applications tend to need a richer service API than REST can provide. Plus, I don't want to spend any more than a couple minutes creating my web service client. The WSDL processing client generation tools allow me to implement my client and move on to adding business value.

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

Now, if I were writing a web service explicitly for some javascript ajax calls, it'd probably be in REST; just for the sake knowing the client technology and leveraging JSON. In my opinion, web service APIs used from javascript probably shouldn't be very complex, as that type of complexity seems to be better handled server-side.

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

With that said, there some SOAP clients for javascript; I know jQuery has one. Thus, SOAP canbe leveraged from javascript; just not as nicely as a REST service returning JSON strings. So if I had a web service that I wanted to be complex enough that it was flexible for an arbitrary number of client technologies and uses, I'd go with SOAP.

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

回答by James Strachan

I'd recommend you go with REST first - if you're using Java look at JAX-RS and the Jerseyimplementation. REST is much simpler and easy to interop in many languages.

我建议您首先使用 REST - 如果您使用 Java，请查看 JAX-RS 和Jersey实现。REST 更简单，更易于在多种语言中进行互操作。

As others have said in this thread, the problem with SOAP is its complexity when the other WS-* specifications come in and there are countless interop issues if you stray into the wrong parts of WSDL, XSDs, SOAP, WS-Addressing etc.

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

The best way to judge the REST v SOAP debate is look on the internet - pretty much all the big players in the web space, google, amazon, ebay, twitter et al - tend to use and prefer RESTful APIs over the SOAP ones.

判断 REST 与 SOAP 争论的最佳方式是查看互联网——几乎所有网络领域的大玩家，谷歌、亚马逊、ebay、twitter 等——都倾向于使用和喜欢 RESTful API，而不是 SOAP API。

The other nice approach to going with REST is that you can reuse lots of code and infratructure between a web application and a REST front end. e.g. rendering HTML versus XML versus JSON of your resources is normally pretty easy with frameworks like JAX-RS and implicit views - plus its easy to work with RESTful resources using a web browser

使用 REST 的另一个好方法是，您可以在 Web 应用程序和 REST 前端之间重用大量代码和基础设施。例如，使用 JAX-RS 和隐式视图之类的框架，渲染资源的 HTML 与 XML 与 JSON 通常非常容易——而且它易于使用 Web 浏览器处理 RESTful 资源

回答by gbjbaanb

I'm sure Don Box created SOAP as a joke - 'look you cancall RPC methods over the web' and today groans when he realises what a bloated nightmare of web standards it has become :-)

我确信 Don Box 创建 SOAP 是为了开玩笑——“看，你可以通过 Web 调用 RPC 方法”，今天当他意识到它已经成为 Web 标准的一个臃肿的噩梦时，他呻吟了 :-)

REST is good, simple, implemented everywhere (so more a 'standard' than the standards) fast and easy. Use REST.

REST 很好，很简单，随处实现（因此更像是一个“标准”而不是标准）又快又容易。使用休息。