RESTful体系结构的优缺点

我所见过的关于REST优缺点的最常见讨论倾向于将有关SOAP的讨论框架化。我都没有经验。我目前面临的决定是我的经验不足，这使我难以评估。我开始开发一个具有多个组件的应用程序-主要是一个管理方面，允许所有者管理多个站点-一个面向公众的用户界面，该界面允许用户与主机上保存的数据进行交互。我需要评估允许将后者托管在任何地方并通过RESTful体系结构与前者进行通信的含义，或者要求两个组件都位于同一主机上。开发RESTful架构的关键含义是什么，尤其是在以下方面的功能方面：

1：安全2：性能3：接口复杂性

编辑：看这个问题的一些答案-我应该澄清。我不是在寻求与SOAP的比较-而是REST应用程序与所有组件都驻留在一台主机上的应用程序的概述。（尽管感谢您的回答！）

考虑到这些领域，我可以粗略地概述一下，但是我不能为您得出结论。两种协议在两个主要方面有所不同：

• 讯息格式
• 服务发现

消息格式最容易理解。请求和响应的SOAP打包都非常繁重。有一个包含标题和正文部分的SOAP信封。标头可被请求链中的多个过滤器用来执行某种形式的标识，授权等。但是，XML解析成本很高，这对系统的可伸缩性产生了一定的影响。多少取决于堆栈中的SOAP处理层。

服务发现可能是您争执最多的地方。REST本质上提供了可预测的端点，并且请求的内容是一个简单的HTTP请求。这样做的好处是没有额外的开销，并且最终用户在了解了您网站的URL结构后，几乎可以猜测如何做所需的事情。当然，天真的安全意识人们会认为这是一个弱点。毕竟，使用SOAP，您必须使用WSDL才能知道端点是什么。当然，使用SOAP，您可以获得完整的消息格式，因此可以进行更有针对性的攻击。

按您提供的类别细分：

安全

哪一种在本质上都比另一种更安全。使用良好的安全性原则：

• 加密通讯
• 在处理之前，请确保您对用户进行身份验证和授权
• 良好的编码习惯，避免直接攻击
• 那只是短名单。

记住晦涩！=安全。

性能

由于遵循简单HTTP协议的请求，原始性能和可伸缩性都将归于REST。大多数SOAP堆栈都使用SAX解析（基于事件的解析），这极大地提高了SOAP堆栈的可伸缩性，但是对开销产生了可观的影响。SOAP除了XML解析开销外，还具有正常的HTTP处理开销。REST仅具有HTTP处理开销。

复杂

从系统的角度来看，REST必胜。移动部件更少，请求链更精简，等等。这意味着更容易实现可靠性。

从程序员的角度来看，如果您使用的IDE或框架为其提供了良好的支持，则SOAP可以胜出。本质上，使用REST，您有责任执行预处理工作（身份验证/授权/等），而使用SOAP，大部分工作都可以通过可插入的处理链来完成。

我的偏好

我对HTTP请求非常满意，而且我知道网络的工作原理。因此，REST方法对我来说更可取。但是，我确实知道我的一些客户对此感到不舒服。他们已经阅读了一些行业文章，这些文章谴责REST与SOAP等的安全性。最重要的是，这两种方法都不保证安全性。您需要确保应用程序的安全性和安全性。显然，社交网络应用程序对安全性的要求（或要求）不如银行或政府系统那么高。许多SOAP堆栈都包含处理器，您可以插入这些处理器以提供某种安全性，但是搜索并放置它们仍然是您的责任。

1. 安全性：使用HTTPS。这对两者都适用。
2. 效果：。REST减少了CPU开销（减少了解析，编组和解包）。同样，使用REST进行缓存也是小菜一碟。
3. 复杂性： REST对设置的要求要少得多，毕竟只是GET / POST。SOAP需要进行更多的维护工作（wsdl等），但是如果您的IDE支持，则要容易一些。

我认为，当您可以使用REST和某些内容/ MIME类型执行相同的操作时，SOAP会变得过于膨胀。同样，由于SOAP的包装性质以及它更通用且不限于HTTP的事实，SOAP也带来了很多开销。如果您的IDE正确地支持SOAP，并且您不想学习HTTP，那么SOAP就很容易使用。但是对我而言，REST更易于使用，并且对网络更友好。

如今，有非常好的REST API可以使用。如果您喜欢Java，那么Jax-RS真的很棒。对于某些人来说，这就像色情。

我认为REST的最大优点是突破了RPC体系结构。REST公开资源，而不是进程。这样，您就可以创建一个松散绑定的系统，其中某个部分的更改，改进甚至失败都会对其他部分产生有限的（负面的）影响。

不幸的是，REST的一个常见误用是公开您的内部数据结构（在最坏的情况下，这是数据库的CRUD，呃）。这使得它非常难以做到这一点安全。正确的用法是公开与您要处理的系统部分相关的高级对象，并在出现任何不一致时自由地返回错误状态代码。

REST另一个经常被忽略的部分是大多数动词的幂等性。如果应用一次或多次，不仅GET，而且PUT和DELETE的结果也应该完全相同（如果已经删除，则无需返回404；如果客户端将其相同，则无需更改）。这导致了健壮的系统，并减少了语义精确解释的相互依赖性。

WS- *标准实际上主要是关于在SOAP / HTTP上运行RPC。因此，进入CORBA和J2EE及其前身的所有思想大部分已转移到使用XML做相同的事情。这意味着诸如类型声明和服务合同，元数据交换，声明性安全性之类的东西。所有这些都是真正的“企业”东西。坦白说，它甚至在企业中也被过度使用。

使用RESTful架构，构建自己的Internet Web应用程序的人们几乎肯定会更好。几乎任何平台都可以使用它，并且可以简单地使用它，而不必担心您使用的是哪个版本的规范以及无数种特定于工具的类型转换怪癖等。

与当前REST实现相比，SOAP的唯一一大优势是SOAP的工具更易于使用-大多数RESTful客户端要求我理解接口并编写某种客户端。对于SOAP，我只需将wsdl.exe指向它，它就会为我生成类。