SOAP与REST(差异)

问题描述

我已经阅读了有关SOAP和REST作为Web服务通信协议之间的区别的文章，但是我认为REST相对于SOAP的最大优势是:

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:

1. REST更动态，无需创建和更新UDDI(通用描述，发现和集成).

1. REST is more dynamic, no need to create and update UDDI(Universal Description, Discovery, and Integration).

REST不仅限于XML格式. RESTful Web服务可以发送纯文本/JSON/XML.

REST is not restricted to only XML format. RESTful web services can send plain text/JSON/XML.

但是SOAP更加标准化(例如，安全性).

But SOAP is more standardized (E.g.: security).

那么，我在这些方面是正确的吗?

So, am I correct in these points?

推荐答案

不幸的是，围绕REST存在许多误解和误解.不仅您的问题和@cmd的答案反映了这些问题，而且大多数与该主题相关的问题和答案溢出.

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和REST，因为第一个是协议(或者至少是协议)，第二个是体系结构样式.这可能是引起混乱的根源之一，因为人们倾向于将REST称为不是SOAP的任何HTTP API.

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.

稍作努力并尝试建立比较，SOAP和REST之间的主要区别在于客户端和服务器实现之间的耦合程度. 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.

REST客户端更像是浏览器.这是一个通用客户端，知道如何使用协议和标准化方法，并且应用程序必须适合其中.您不会通过创建其他方法来违反协议标准，而是可以使用标准方法并在您的媒体类型上使用它们来创建操作.如果做得正确，耦合度就会降低，并且可以更优雅地处理更改.除了入口点和媒体类型之外，客户端应该以对API零知识的方式进入REST服务.在SOAP中，客户端需要有关将要使用的所有内容的先前知识，或者甚至不会开始交互.此外，REST客户端可以通过服务器本身提供的按需代码进行扩展，经典示例是用于驱动与客户端另一服务交互的JavaScript代码.

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.

我认为这些是了解REST的含义以及与SOAP有何不同的关键点:

I think these are the crucial points to understand what REST is about, and how it differs from SOAP:

• REST与协议无关.它没有与HTTP耦合.就像您可以在网站上访问ftp链接一样，REST应用程序可以使用具有标准化URI方案的任何协议.

• 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不是CRUD到HTTP方法的映射.阅读此答案，以对此进行详细说明.

REST is not a mapping of CRUD to HTTP methods. Read this answer for a detailed explanation on that.

REST与您所使用的部件一样标准化. HTTP中的安全性和身份验证是标准化的，因此这就是在HTTP上进行REST时使用的方式.

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.

没有超级媒体和 HATEOAS .这意味着客户端仅知道入口点URI，并且资源应返回客户端应遵循的链接.这些花哨的文档生成器为您在REST API中可以执行的所有操作提供URI模式，这完全忽略了这一点.他们不仅在记录本应遵循该标准的内容，而且在这样做时，您将客户端与API演进中的特定时刻联系在一起，并且必须对API上的任何更改进行记录和应用，否则会破裂.

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是Web本身的体系结构样式.当您输入Stack Overflow时，您知道用户，问题和答案是什么，您知道媒体类型，并且网站为您提供了指向它们的链接. REST API必须执行相同的操作.如果我们以人们认为REST的方式设计网络，而不是使用带有问题和答案链接的主页来代替，我们将有一份静态文档来说明，为了查看问题，您必须使用URI stackoverflow.com/questions/<id>，将ID替换为Question.id，然后将其粘贴到浏览器中.那是胡说八道，但这就是许多人认为REST的含义.

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.

最后一点不能被充分强调.如果您的客户是从文档中的模板构建URI，而未在资源表示中获得链接，则不是REST. REST的作者Roy Fielding在此博客文章中明确指出: REST API必须是超文本驱动的.

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.

考虑到以上几点，您将认识到，尽管REST可能不限于XML，但要正确地使用任何其他格式来实现它，则必须为链接设计和标准化某种格式.超链接是XML的标准配置，但不是JSON的标准配置.有JSON的标准草案，例如 HAL .

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.

最后，REST并不适合每个人，这证明了大多数人如何使用错误地称为REST的HTTP API很好地解决他们的问题，并且永不冒险. REST有时很难做到，尤其是在开始时，但是随着时间的流逝，它会在服务器端更轻松地演进以及客户对变化的适应力中付出代价.如果您需要快速，轻松地完成某件事，请不要担心正确使用REST.可能不是您要找的东西.如果您需要某些东西必须保持在线状态长达数年甚至数十年，那么REST就适合您.

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(差异)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！