SOAP 与 REST(差异) [英] SOAP vs REST (differences)
问题描述
我读过有关 SOAP 和 REST 作为 Web 服务通信协议的区别的文章，但我认为 REST 相对于 SOAP 的最大优势是:
REST 更具动态性，无需创建和更新 UDDI(通用描述、发现和集成).
REST 不仅限于 XML 格式.RESTful Web 服务可以发送纯文本/JSON/XML.
但是 SOAP 更加标准化(例如:安全性).
那么，我在这些方面是否正确?
不幸的是，关于 REST 存在很多错误信息和误解.不仅您的问题和 @cmd 的回答 反映了这些，而且与 Stack 上的主题相关的大多数问题和答案溢出.
SOAP 和 REST 不能直接比较，因为第一个是协议(或至少试图成为)，第二个是架构风格.这可能是造成混淆的原因之一，因为人们倾向于将 REST 称为任何非 SOAP 的 HTTP API.
稍微推一下，试图建立一个比较，SOAP 和 REST 之间的主要区别在于客户端和服务器实现之间的耦合程度.SOAP 客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合.客户端和服务器之间有严格的契约，如果任何一方改变任何事情，一切都会破裂.您需要在任何更改后不断更新，但更容易确定合同是否得到遵守.
REST 客户端更像是一个浏览器.它是一个知道如何使用协议和标准化方法的通用客户端，应用程序必须适应其中.您不会通过创建额外的方法来违反协议标准，您可以利用标准方法并在您的媒体类型上使用它们创建操作.如果处理得当，耦合就会减少，并且可以更优雅地处理更改.除了入口点和媒体类型之外，客户端应该在对 API 零知识的情况下进入 REST 服务.在 SOAP 中，客户端需要事先了解它将使用的所有内容，否则它甚至不会开始交互.此外，REST 客户端可以通过服务器本身提供的按需代码进行扩展，经典示例是用于驱动与客户端其他服务的交互的 JavaScript 代码.
我认为这些是理解 REST 是什么以及它与 SOAP 有何不同的关键点:
REST 独立于协议.它没有与 HTTP 耦合.就像您可以访问网站上的 ftp 链接一样，REST 应用程序可以使用任何具有标准化 URI 方案的协议.
REST 不是 CRUD 到 HTTP 方法的映射.阅读这个答案以获得对此的详细解释.p>
REST 与您使用的部件一样标准化.HTTP 中的安全性和身份验证是标准化的，因此这就是您在通过 HTTP 执行 REST 时使用的内容.
如果没有超媒体和HATEOAS.这意味着客户端只知道入口点 URI 并且资源应该返回客户端应该遵循的链接.那些花哨的文档生成器为您在 REST API 中可以做的所有事情提供 URI 模式，完全没有抓住重点.他们不仅记录了应该遵循标准的东西，而且当您这样做时，您将客户端与 API 发展中的一个特定时刻耦合，并且必须记录和应用 API 上的任何更改，否则它会坏掉.
REST 是 Web 本身的架构风格.当您进入 Stack Overflow 时，您知道用户、问题和答案是什么，您知道媒体类型，并且网站为您提供了指向它们的链接.REST API 也必须这样做.如果我们按照人们认为 REST 应该完成的方式来设计 Web，而不是有一个包含问题和答案链接的主页，我们将有一个静态文档解释说为了查看问题，您必须使用 URI
stackoverflow.com/questions/，将 id 替换为 Question.id 并将其粘贴到您的浏览器上.这是无稽之谈，但这就是许多人认为 REST 的意义所在.
最后一点再怎么强调都不为过.如果您的客户从文档中的模板构建 URI，并且没有在资源表示中获取链接，那么这不是 REST.REST 的作者 Roy Fielding 在这篇博文中说得很清楚:REST API 必须是超文本驱动的.
考虑到上述内容，您会意识到虽然 REST 可能不限于 XML，但要使用任何其他格式正确执行此操作，您必须为链接设计和标准化某些格式.超链接在 XML 中是标准的，但在 JSON 中不是.JSON 有一些标准草案，例如 HAL.
最后，REST 并不适合所有人，这证明了大多数人如何使用他们错误地称为 REST 的 HTTP API 很好地解决了他们的问题，并且从不冒险超越它.REST 有时很难做到，尤其是在开始时，但随着时间的推移，服务器端更容易进化，客户端对变化的适应能力也会随着时间的推移而付出代价.如果您需要快速轻松地完成某件事，请不要担心正确使用 REST.这可能不是你要找的.如果您需要一些必须保持在线状态数年甚至数十年的东西，那么 REST 适合您.
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:
REST is more dynamic, no need to create and update UDDI(Universal Description, Discovery, and Integration).
REST is not restricted to only XML format. RESTful web services can send plain text/JSON/XML.
But SOAP is more standardized (E.g.: security).
So, am I correct in these points?
Unfortunately, there are a lot of misinformation and misconceptions around 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.
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. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP.
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. A SOAP client works like a custom desktop application, tightly coupled to the server. 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. 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. In SOAP, the client needs previous knowledge on everything it will be using, or it won't even begin the interaction. 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.
I think these are the crucial points to understand what REST is about, and how it differs from SOAP:
REST is protocol independent. It's not coupled to 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.
REST is not a mapping of CRUD to HTTP methods. Read this answer for a detailed explanation on that.
REST is as standardized as the parts you're using. Security and authentication in HTTP are standardized, so that's what you use when doing REST over HTTP.
REST is not REST without hypermedia and HATEOAS. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. 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.
REST is the architectural style of the web itself. 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. A REST API has to do the same. 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. That's nonsense, but that's what many people think REST is.
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. Roy Fielding, the author of REST, made it clear on this blog post: REST APIs must be hypertext-driven.
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. Hyperlinks are standard in XML, but not in JSON. There are draft standards for JSON, like 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 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. If you need something done quickly and easily, don't bother about getting REST right. 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.
这篇关于SOAP 与 REST(差异)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
