RESTful与基于SOAP的Web服务？

Question

我最近通过webservices一书，其中涉及基于SOAP的Web服务和RESTful Web服务。 我不确定我应该选择哪一个参数，因为它们看起来相似（甚至从开发人员的角度来看）。以下是我的观点

在SOAP webservices中，我们使用从webservices生成的WSDL文件，然后基于此创建客户端存根。

  

我的理解是内部存根也将使用HTTP协议   与远程java webservice通信。正确？

此处HTTP请求/响应正文中将包含SOAP消息（XML消息）。因此，在基于REST的Web服务中，要再向下钻取一层，HTTP请求本身就像消息一样。这里我们有WADL而不是WSDL。在这里我们也可以基于WADL创建存根。因此，除了一些技术差异外，每件事情看起来或多或少相同 消费者连接到生产者以及如何处理请求/响应。根据我的理解，从开发人员的角度来看，基于w / rest和基于SOAP的Web服务没有太大区别（开发人员的工作量几乎相同）。

我的理解是否正确？

是可能在幕后，可能SOAP比SOAP中的REST webservices becoz更复杂，消息内部有消息（SOAP消息嵌入在HTTP请求中），但在基于REST的服务中，HTTP请求本身作为消息。

Answer 1

SOAP和REST旨在解决一组相同的问题，即以最简单的方式促进异构应用程序之间的交互。现在，是否选择REST或SOAP不仅取决于开发工作量。您还应该考虑以下一些因素，

1. 数据类型是否只是简单的对象（如名称值对）或非常复杂的模式（或某些二进制数据）在应用程序之间进行交换。
2. 您服务的消费者。例如。在开发RIA时，REST更适合。
3. 安全要求。 SOAP凭借标准驱动，提供了非常精细的安全方面的粒度调整。您可以对SOAP xml消息的各个元素进行编码。这些类型的东西在REST中是不可能的（至少现在）。
4. 如今， JSON 这样的符号在轻量级数据交换中非常流行，而且许多REST服务框架都非常容易开箱即用。
5. 从技术上讲，您不需要任何框架等来创建REST Web服务。我知道WADL等最近引入了一个标准化元素，但是甚至在WADL出现之前REST就存在了。 REST并不是什么新鲜事，它的网络运作方式。 REST框架使它变得非常容易。

SOAP是由标准驱动的，因此在使用它们时会有更多的限制。因此，如果您使用案例很简单（那是非常主观的），请选择REST。

Answer 2

这是开发Web服务的两种不同方式......关于它们的差异（和优势）有很多讨论。

SOAP Web服务远不止您所指的那些点，实际上有一个完整的“堆栈”（WS- *），旨在标准化设计和实现此类Web服务的方法。这对某些系统来说很不错，但对于其他系统而言，它“太多”而且很重。在幕后，HTTP是一种流行的“传输”消息的方式，但它不是唯一的，它们可以通过其他协议实现。在SOAP中，您严重依赖于“WSDL”规范，该规范确实可用于“生成”服务器和客户端代码。在这些规范中，您非常关注“操作”，即在Web服务上要做的事情。

另一方面，在REST上我们更多地考虑“资源”（由给定的URI描述），然后通过它我们执行HTTP操作。虽然WADL存在，但在SOAP Web服务中没有那么多规范的概念。实际上一个很大的区别，人们并没有多想（但实际上是REST原则的核心部分），在REST中你有所谓的“超链接”，其目的是允许客户端 - 服务器进行通信“状态”（接下来要去哪里），这在SOAP Web服务中不是那么“动态”处理。

总的来说，对于开发人员而言：SOAP确实有很多很好的工具（例如：所有Eclipse Web服务工具），但它往往有点麻烦和很多“代码”。 REST开发通常更简洁。我认为这两种解决方案都可以用作你正在处理的情况的函数，你不应该“选择一个”。例如，如果你有一个巨大的企业应用程序，有很多部件和相互依赖关系，事务处理等，可能是带有WSDL（契约）的SOAP Web服务。另一方面，如果您向客户端公开一个Web服务（或API），没有很多相互依赖性，那么REST可能是最有趣的（您可以在我们在过去5年左右所获得的更改中看到这一点，其中所有主要Web APIS - 谷歌，推特等，现在都公开为REST网络服务。）

Answer 3

没有太大的差异（特别是来自开发人员的观点）。

唯一真正的区别是SOAP是使用WS- *建议标准化的。同样在SOAP中，有可能创建事务并根据标准保护消息本身。因此，对于互操作性，SOAP具有基于此的优势。