本文翻译自：SOAP vs REST (differences)
I have read articles about the differences between SOAP and REST as a web service communication protocol, but I think that the biggest advantages for REST over SOAP are: 我已经阅读了有关SOAP和REST作为Web服务通信协议之间的区别的文章，但是我认为REST相对于SOAP的最大优势在于：
REST is more dynamic, no need to create and update UDDI(Universal Description, Discovery, and Integration). REST更动态，无需创建和更新UDDI（通用描述，发现和集成）。
REST is not restricted to only XML format. REST不仅限于XML格式。 RESTful web services can send plain text/JSON/XML. RESTful Web服务可以发送纯文本/ JSON / XML。
But SOAP is more standardized (Eg: security). 但是SOAP更加标准化（例如：安全性）。
So, am I correct in these points? 那么，我在这些方面是否正确？
#1楼
参考：https://stackoom.com/question/1LQoR/SOAP与REST-差异
#2楼
REST vs SOAP is not the right question to ask. REST vs SOAP 不是正确的问题。
REST , unlike SOAP is not a protocol. REST与SOAP不同，它不是协议。
REST is an architectural style and a design for network-based software architectures. REST是一种架构风格和基于网络的软件架构设计 。
REST concepts are referred to as resources. REST概念称为资源。 A representation of a resource must be stateless. 资源的表示形式必须是无状态的。 It is represented via some media type. 它通过某种媒体类型表示。 Some examples of media types include XML , JSON , and RDF . 媒体类型的一些示例包括XML ， JSON和RDF 。 Resources are manipulated by components. 资源由组件操纵。 Components request and manipulate resources via a standard uniform interface. 组件通过标准的统一接口请求和操纵资源。 In the case of HTTP, this interface consists of standard HTTP ops eg GET , PUT , POST , DELETE . 对于HTTP，此接口由标准HTTP操作组成，例如GET ， PUT ， POST ， DELETE 。
@Abdulaziz's question does illuminate the fact that REST and HTTP are often used in tandem. @Abdulaziz的问题确实说明了REST和HTTP经常串联使用的事实。 This is primarily due to the simplicity of HTTP and its very natural mapping to RESTful principles. 这主要是由于HTTP的简单性及其对RESTful原理的非常自然的映射。
Fundamental REST Principles REST基本原理
Client-Server Communication 客户端-服务器通信
Client-server architectures have a very distinct separation of concerns. 客户端-服务器体系结构的关注点非常不同。 All applications built in the RESTful style must also be client-server in principle. 原则上，以RESTful样式构建的所有应用程序也必须是客户端服务器。
Stateless 无状态
Each client request to the server requires that its state be fully represented. 每个对服务器的客户端请求都要求完全表示其状态。 The server must be able to completely understand the client request without using any server context or server session state. 服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态。 It follows that all state must be kept on the client. 因此，所有状态都必须保留在客户端上。
Cacheable 可缓存
Cache constraints may be used, thus enabling response data to be marked as cacheable or not-cacheable. 可以使用缓存约束，从而使响应数据可以标记为可缓存或不可缓存。 Any data marked as cacheable may be reused as the response to the same subsequent request. 任何标记为可缓存的数据都可以重用作为对相同后续请求的响应。
Uniform Interface 统一接口
All components must interact through a single uniform interface. 所有组件都必须通过一个统一的界面进行交互。 Because all component interaction occurs via this interface, interaction with different services is very simple. 因为所有组件交互都是通过此接口发生的，所以与不同服务的交互非常简单。 The interface is the same! 界面是一样的！ This also means that implementation changes can be made in isolation. 这也意味着可以单独进行实现更改。 Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. 这样的更改不会影响基本组件的交互，因为统一接口始终不变。 One disadvantage is that you are stuck with the interface. 一个缺点是您被接口卡住了。 If an optimization could be provided to a specific service by changing the interface, you are out of luck as REST prohibits this. 如果可以通过更改接口来为特定服务提供优化，则您很不走运，因为REST禁止这样做。 On the bright side, however, REST is optimized for the web, hence incredible popularity of REST over HTTP! 从好的方面来说，REST是针对Web优化的，因此REST在HTTP上的普及程度令人难以置信！
The above concepts represent defining characteristics of REST and differentiate the REST architecture from other architectures like web services. 以上概念代表了REST的定义特征，并将REST体系结构与其他体系结构（如Web服务）区分开来。 It is useful to note that a REST service is a web service, but a web service is not necessarily a REST service. 值得注意的是，REST服务是Web服务，但是Web服务不一定是REST服务。
See this blog post on REST Design Principles for more details on REST and the above stated bullets. 有关REST和上述项目符号的更多详细信息，请参见有关REST设计原则的博客文章 。
EDIT: update content based on comments 编辑： 根据评论更新内容
#3楼
Unfortunately, there are a lot of misinformation and misconceptions around REST. 不幸的是，关于REST有很多误解和误解。 Not only your question and the answer by @cmd reflect those, but most of the questions and answers related to the subject on Stack Overflow. @cmd不仅反映了您的问题和答案 ，而且与Stack Overflow上的主题相关的大多数问题和答案。
SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. SOAP和REST无法直接进行比较，因为第一个是协议（或至少是协议），第二个是体系结构样式。 This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP. 这可能是引起混乱的根源之一，因为人们倾向于将REST称为不是SOAP的任何HTTP API。
Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. 稍作努力并尝试建立比较，SOAP和REST之间的主要区别在于客户端和服务器实现之间的耦合程度。 A SOAP client works like a custom desktop application, tightly coupled to the server. SOAP客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合。 There's a rigid contract between client and server, and everything is expected to break if either side changes anything. 客户端和服务器之间存在严格的合同，如果任何一方更改任何内容，一切都会中断。 You need constant updates following any change, but it's easier to ascertain if the contract is being followed. 在进行任何更改后，您需要不断更新，但更容易确定是否遵守合同。
A REST client is more like a browser. REST客户端更像是浏览器。 It's a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. 这是一个通用客户端，知道如何使用协议和标准化方法，并且应用程序必须适合其中。 You don't violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. 您不会通过创建其他方法来违反协议标准，而是可以使用标准方法并在您的媒体类型上使用它们来创建操作。 If done right, there's less coupling, and changes can be dealt with more gracefully. 如果做得正确，耦合度就会降低，并且可以更优雅地处理更改。 A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. 除了入口点和媒体类型之外，客户端应该以对API零知识的方式进入REST服务。 In SOAP, the client needs previous knowledge on everything it will be using, or it won't even begin the interaction. 在SOAP中，客户端需要有关将要使用的所有内容的先前知识，或者甚至不会开始交互。 Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being JavaScript code used to drive the interaction with another service on the client-side. 另外，REST客户端可以通过服务器本身提供的按需代码进行扩展，经典示例是JavaScript代码，该代码用于驱动与客户端另一服务的交互。
I think these are the crucial points to understand what REST is about, and how it differs from SOAP: 我认为这些是了解REST的意义以及与SOAP有何不同的关键点：
REST is protocol independent. REST与协议无关。 It's not coupled to HTTP. 它没有耦合到HTTP。 Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is a standardized URI scheme. 就像您可以在网站上跟随ftp链接一样，REST应用程序可以使用具有标准化URI方案的任何协议。
REST is not a mapping of CRUD to HTTP methods. REST不是CRUD到HTTP方法的映射。 Read this answer for a detailed explanation on that. 阅读此答案以获取有关此内容的详细说明。
REST is as standardized as the parts you're using. REST与您使用的部件一样标准化。 Security and authentication in HTTP are standardized, so that's what you use when doing REST over HTTP. HTTP中的安全性和身份验证是标准化的，因此这就是在HTTP上进行REST时使用的方式。
REST is not REST without hypermedia and HATEOAS . 没有超媒体和HATEOAS的 REST就不是REST。 This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. 这意味着客户端仅知道入口点URI，并且资源应返回客户端应遵循的链接。 Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. 这些花哨的文档生成器为您在REST API中可以执行的所有操作提供URI模式，这完全忽略了这一点。 They are not only documenting something that's supposed to be following the standard, but when you do that, you're coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break. 他们不仅在记录本应遵循该标准的内容，而且在这样做时，您将客户端与API演进中的特定时刻联系在一起，并且必须记录和应用API上的任何更改，否则会破裂。
REST is the architectural style of the web itself. REST是Web本身的体系结构样式。 When you enter Stack Overflow, you know what a User, a Question and an Answer are, you know the media types, and the website provides you with the links to them. 当您输入Stack Overflow时，您知道什么是用户，问题和答案，媒体类型，并且网站为您提供了指向它们的链接。 A REST API has to do the same. REST API必须执行相同的操作。 If we designed the web the way people think REST should be done, instead of having a home page with links to Questions and Answers, we'd have a static documentation explaining that in order to view a question, you have to take the URI
stackoverflow.com/questions/<id>, replace id with the Question.id and paste that on your browser. 如果我们以人们认为REST的方式设计网络，而不是使用带有问答链接的主页，则将有一个静态文档说明要查看问题，您必须采取URIstackoverflow.com/questions/<id>，将ID替换为Question.id并将其粘贴到浏览器中。 That's nonsense, but that's what many people think REST is. 那是胡扯，但这就是许多人认为REST的含义。
This last point can't be emphasized enough. 最后一点不能足够强调。 If your clients are building URIs from templates in documentation and not getting links in the resource representations, that's not REST. 如果您的客户是从文档中的模板构建URI，而未在资源表示中获得链接，则不是REST。 Roy Fielding, the author of REST, made it clear on this blog post: REST APIs must be hypertext-driven . REST的作者Roy Fielding在此博客文章中明确指出： REST API必须是超文本驱动的 。
With the above in mind, you'll realize that while REST might not be restricted to XML, to do it correctly with any other format you'll have to design and standardize some format for your links. 考虑到以上几点，您将认识到，尽管REST可能不限于XML，但要正确地使用其他任何格式，则必须为链接设计和标准化某种格式。 Hyperlinks are standard in XML, but not in JSON. 超链接是XML的标准配置，但不是JSON的标准配置。 There are draft standards for JSON, like HAL . 有JSON的标准草案，例如HAL 。
Finally, REST isn't for everyone, and a proof of that is how most people solve their problems very well with the HTTP APIs they mistakenly called REST and never venture beyond that. 最后，REST并不适合所有人，这证明了大多数人如何使用错误地称为REST的HTTP API很好地解决他们的问题，并且永不冒险。 REST is hard to do sometimes, especially in the beginning, but it pays over time with easier evolution on the server side, and client's resilience to changes. REST有时很难做到，尤其是在开始时，但是随着时间的流逝，它会在服务器端更轻松地演进以及客户对变更的适应力中付出代价。 If you need something done quickly and easily, don't bother about getting REST right. 如果您需要快速，轻松地完成某件事，请不要担心正确使用REST。 It's probably not what you're looking for. 可能不是您要找的东西。 If you need something that will have to stay online for years or even decades, then REST is for you. 如果您需要某些东西必须保持在线状态长达数年甚至数十年，那么REST适合您。
#4楼
SOAP ( Simple Object Access Protocol ) and REST ( Representation State Transfer ) both are beautiful in their way. SOAP（ 简单对象访问协议 ）和REST（ 表示状态传输 ）两者的方式都很漂亮。 So I am not comparing them. 所以我没有比较它们。 Instead, I am trying to depict the picture, when I preferred to use REST and when SOAP. 相反，当我更喜欢使用REST和SOAP时，我试图描绘出这张图。
What is payload? 什么是有效载荷？
When data is sent over the Internet, each unit transmitted includes both header information and the actual data being sent. 当数据通过Internet发送时，每个发送的单元都包括标头信息和实际发送的数据。 The header identifies the source and destination of the packet, while the actual data is referred to as the payload . 标头标识数据包的源和目的地， 而实际数据称为有效负载 。 In general, the payload is the data that is carried on behalf of an application and the data received by the destination system. 通常，有效负载是代表应用程序承载的数据和目标系统接收的数据。
Now, for example, I have to send a Telegram and we all know that the cost of the telegram will depend on some words. 例如，现在我必须发送电报 ，我们都知道电报的费用将取决于某些单词。
So tell me among below mentioned these two messages, which one is cheaper to send? 因此，请在下面提到的这两个消息中告诉我，哪个消息发送起来更便宜？
<name>Arin</name>
or 要么
"name": "Arin"
I know your answer will be the second one although both representing the same message second one is cheaper regarding cost. 我知道您的答案将是第二个，尽管两者都表示相同的消息。第二个在成本方面更便宜。
So I am trying to say that, sending data over the network in JSON format is cheaper than sending it in XML format regarding payload . 因此，我想说的是， 以JSON格式通过网络发送数据要比以XML格式发送有关有效负载的数据便宜 。
Here is the first benefit or advantages of REST over SOAP . 这是REST相对于SOAP的第一个优点或优点 。 SOAP only support XML, but REST supports different format like text, JSON, XML, etc. And we already know, if we use Json then definitely we will be in better place regarding payload. SOAP仅支持XML，但是REST支持不同的格式，例如文本，JSON，XML等。而且我们已经知道，如果使用Json，那么在有效负载方面肯定会处于更好的位置。
Now, SOAP supports the only XML, but it also has its advantages. 现在，SOAP仅支持XML， 但也有其优势。
Really! 真！ How? 怎么样？
SOAP relies on XML in three ways Envelope – that defines what is in the message and how to process it. SOAP通过三种方式依赖XML信封-定义消息中包含的内容以及如何对其进行处理。
A set of encoding rules for data types, and finally the layout of the procedure calls and responses gathered. 一组用于数据类型的编码规则，最后是过程调用和响应的布局。
This envelope is sent via a transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed, and the envelope is returned with information in an XML formatted document. 该信封通过传输（HTTP / HTTPS）发送，并执行RPC（远程过程调用），并且信封以XML格式的文档中的信息返回。
The important point is that one of the advantages of SOAP is the use of the “generic” transport but REST uses HTTP/HTTPS . 重要的一点是， SOAP的优点之一是使用“通用”传输，而REST使用HTTP / HTTPS 。 SOAP can use almost any transport to send the request but REST cannot. SOAP几乎可以使用任何传输方式发送请求，而REST不能。 So here we got an advantage of using SOAP. 因此，这里我们有了使用SOAP的优势。
As I already mentioned in above paragraph “REST uses HTTP/HTTPS” , so go a bit deeper on these words. 正如我在上一段“ REST使用HTTP / HTTPS”中已经提到的那样，请对这些词进行更深入的介绍。
When we are talking about REST over HTTP, all security measures applied HTTP are inherited, and this is known as transport level security and it secures messages only while it is inside the wire but once you delivered it on the other side you don't know how many stages it will have to go through before reaching the real point where the data will be processed. 当我们谈论基于HTTP的REST时，HTTP所应用的所有安全措施都是继承的，这就是所谓的传输级安全性 ，它仅在消息位于线路内部时保护消息的安全 ，但是一旦在另一端传递消息，您就不会知道在到达将要处理数据的实际点之前，它必须经历多少个阶段。 And of course, all those stages could use something different than HTTP. 当然，所有这些阶段都可以使用与HTTP不同的东西。 So Rest is not safer completely, right? 因此，休息并不完全安全，对吗？
But SOAP supports SSL just like REST additionally it also supports WS-Security which adds some enterprise security features. 但是SOAP像REST一样支持SSL ，它还支持WS-Security ，它增加了一些企业安全性功能。 WS-Security offers protection from the creation of the message to it's consumption . WS-Security提供了从创建消息到使用消息的保护。 So for transport level security whatever loophole we found that can be prevented using WS-Security. 因此，对于传输级安全性，我们发现可以使用WS-Security避免的任何漏洞。
Apart from that, as REST is limited by it's HTTP protocol so it's transaction support is neither ACID compliant nor can provide two-phase commit across distributed transnational resources. 除此之外，由于REST受HTTP协议的限制，因此它的事务支持既不符合ACID，也不能提供跨分布式跨国资源的两阶段提交。
But SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. 但是SOAP全面支持短期交易的基于ACID的交易管理和长期交易的基于补偿的交易管理。 It also supports two-phase commit across distributed resources . 它还支持跨分布式资源的两阶段提交 。
I am not drawing any conclusion, but I will prefer SOAP-based web service while security, transaction, etc. are the main concerns. 我没有得出任何结论，但是我将更喜欢基于SOAP的Web服务，而安全，事务等是主要关注点。
Here is the "The Java EE 6 Tutorial" where they have said A RESTful design may be appropriate when the following conditions are met . 在这里的“ Java EE 6教程”中， 当满足以下条件时 ，他们说RESTful设计可能是合适的 。 Have a look. 看一看。
Hope you enjoyed reading my answer. 希望您喜欢阅读我的回答。
#5楼
REST ( RE presentational S tate T ransfer) REST（RE表象的小号泰特贸易交接）
RE presentational S tate of an Object is T ransferred is REST ie we don't send Object, we send state of Object. RE表象S上的对象为T ransferred是REST，即我们不会发送对象，我们发送对象的状态泰特。 REST is an architectural style. REST是一种建筑风格。 It doesn't define so many standards like SOAP. 它没有定义很多标准，例如SOAP。 REST is for exposing Public APIs(ie Facebook API, Google Maps API) over the internet to handle CRUD operations on data. REST用于通过Internet公开公共API（即Facebook API，Google Maps API）以处理数据的CRUD操作。 REST is focused on accessing named resources through a single consistent interface. REST专注于通过单个一致的接口访问命名资源。
SOAP ( S imple O bject A ccess P rotocol) SOAP（šimpleöbject 甲 CCESS P rotocol）
SOAP brings its own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP带来了自己的协议，并着重于将应用程序逻辑部分（而非数据）公开为服务。 SOAP exposes operations. SOAP公开操作。 SOAP is focused on accessing named operations, each operation implement some business logic. SOAP专注于访问命名操作，每个操作实现一些业务逻辑。 Though SOAP is commonly referred to as web services this is misnomer. 尽管SOAP通常被称为Web服务，但这是错误的称呼。 SOAP has a very little if anything to do with the Web. SOAP与Web几乎没有关系。 REST provides true Web services based on URIs and HTTP. REST提供基于URI和HTTP的真正的Web服务 。
Why REST? 为什么要REST？
- Since REST uses standard HTTP it is much simpler in just about ever way. 由于REST使用标准的HTTP，因此它几乎在所有方面都更加简单。
- REST is easier to implement, requires less bandwidth and resources. REST更易于实现，需要更少的带宽和资源。
- REST permits many different data formats where as SOAP only permits XML. REST允许许多不同的数据格式，而SOAP仅允许XML。
- REST allows better support for browser clients due to its support for JSON. REST由于支持JSON，因此可以更好地支持浏览器客户端。
- REST has better performance and scalability. REST具有更好的性能和可伸缩性。 REST reads can be cached, SOAP based reads cannot be cached. 可以缓存REST读取，不能缓存基于SOAP的读取。
- If security is not a major concern and we have limited resources. 如果安全不是主要问题，并且我们的资源有限。 Or we want to create an API that will be easily used by other developers publicly then we should go with REST. 或者，我们想创建一个可供其他开发者公开使用的API，那么我们应该使用REST。
- If we need Stateless CRUD operations then go with REST. 如果我们需要无状态CRUD操作，请使用REST。
- REST is commonly used in social media, web chat, mobile services and Public APIs like Google Maps. REST通常用于社交媒体，网络聊天，移动服务和Google Maps等公共API。
- RESTful service return various MediaTypes for the same resource, depending on the request header parameter "Accept" as
application/xmlorapplication/jsonfor POST and/user/1234.jsonor GET/user/1234.xmlfor GET. RESTful服务回报各种MediaTypes对于相同的资源，根据请求报头参数“接受”作为application/xml或application/json为POST和/user/1234.json或GET/user/1234.xml为GET。 - REST services are meant to be called by the client-side application and not the end user directly. REST服务应由客户端应用程序而不是最终用户直接调用。
- ST in REST comes from S tate T ransfer. ST中其余则选自S大老贸易交接。 You transfer the state around instead of having the server store it, this makes REST services scalable. 您转移状态而不是由服务器存储状态，这使REST服务具有可伸缩性。
Why SOAP? 为什么要使用SOAP？
- SOAP is not very easy to implement and requires more bandwidth and resources. SOAP并不是很容易实现，并且需要更多的带宽和资源。
- SOAP message request is processed slower as compared to REST and it does not use web caching mechanism. 与REST相比，处理SOAP消息请求的速度较慢，并且不使用Web缓存机制。
- WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. WS-Security：尽管SOAP支持SSL（就像REST一样），但它也支持WS-Security，它增加了一些企业安全性功能。
- WS-AtomicTransaction: Need ACID Transactions over a service, you're going to need SOAP. WS-AtomicTransaction：在服务上需要ACID事务，您将需要SOAP。
- WS-ReliableMessaging: If your application needs Asynchronous processing and a guaranteed level of reliability and security. WS-ReliableMessaging：如果您的应用程序需要异步处理以及有保证的可靠性和安全性。 Rest doesn't have a standard messaging system and expects clients to deal with communication failures by retrying. Rest没有标准的消息传递系统，希望客户端通过重试来处理通信失败。
- If the security is a major concern and the resources are not limited then we should use SOAP web services. 如果安全是主要问题，并且资源没有限制，那么我们应该使用SOAP Web服务。 Like if we are creating a web service for payment gateways, financial and telecommunication related work then we should go with SOAP as here high security is needed. 就像我们要创建用于支付网关，金融和电信相关工作的Web服务一样，我们应该使用SOAP，因为这里需要很高的安全性。
#6楼
IMHO you can't compare SOAP and REST where those are two different things. 恕我直言，您无法比较SOAP和REST，因为两者是两个不同的地方。
SOAP is a protocol and REST is a software architectural pattern. SOAP是一种协议， REST是一种软件体系结构模式。 There is a lot of misconception in the internet for SOAP vs REST . 互联网上对于SOAP与REST有很多误解。
SOAP defines XML based message format that web service-enabled applications use to communicate each other over the internet. SOAP定义了基于XML的消息格式，支持Web服务的应用程序使用该消息格式通过Internet相互通信。 In order to do that the applications need prior knowledge of the message contract, datatypes, etc.. 为了做到这一点，应用程序需要消息合约，数据类型等方面的先验知识。
REST represents the state(as resources) of a server from an URL.It is stateless and clients should not have prior knowledge to interact with server beyond the understanding of hypermedia. REST通过URL表示服务器的状态（作为资源），它是无状态的，并且客户端不应该具有对超媒体的了解，与服务器进行交互的先验知识。
扫一扫
83
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
