Question

我听说过SOAP / HTTP Web服务调用堆栈“厚”或“重量级”的一些观点，但我无法确定原因。由于SOAP信封和消息的序列化/反序列化，它会被认为是厚的吗？这真的是一个重量级的操作吗？

或者与固定连接上的原始/二进制数据传输相比，它只被认为是“厚”吗？

还是其他原因？任何人都可以对此有所了解吗？

Answer 1

SOAP的设计足够抽象，可以使用除HTTP之外的其他传输。这意味着，除其他外，它不利用HTTP的某些方面（主要是REST和URL方法的使用，例如PUT /customers/1234或GET /customers/1234）。

SOAP也出于同样的原因绕过现有的TCP / IP机制 - 与传输无关。同样，这意味着它无法利用传输，例如序列管理，流量控制，服务发现（例如{{1}在一个众所周知的端口上建立连接意味着服务存在）等等。

SOAP使用XML进行所有序列化 - 虽然这意味着只使用XML解析器就可以“普遍读取”数据，但它引入了如此多的样板，以便您真正需要SOAP解析器才能高效运行。此时，您（作为软件消费者）已经失去了XML的好处;如果您需要accept()来处理它，那么谁会关心有线电视在电线上的样子。

SOAP需要WSDL才能描述接口。 WSDL本身不是一个问题，但它往往被宣传为比实际更“动态”。在许多情况下，会创建一个WSDL，并从中自动生成生产者/消费者代码，并且它永远不会更改。总的来说，这需要大量的工具，而不是更好地解决原始问题（如何在不同服务器之间进行通信）。由于大多数SOAP服务都是通过HTTP运行的，因此最初的问题已经主要解决了。

Answer 2

SOAP和WSDL是极其复杂的标准，它有许多支持标准不同子集的实现。 SOAP不像XML-RPC那样很好地映射到简单的外部函数接口。相反，您必须了解XML命名空间，包络，标头，WSDL，XML模式等，以生成正确的SOAP消息。调用XML-RPC服务所需要做的就是定义和端点并在其上调用方法。例如，在Ruby中：

require 'xmlrpc/client'

server = XMLRPC::Client.new2("http://example.com/api")
result = server.call("add", 1, 2)

除了XML-RPC之外，还有其他技术也可以更加简单和轻量级，例如纯XML或HTTP上的JSON（通常称为REST，尽管这意味着某些其他技术设计注意事项）。 XML或JSON over HTTP之类的优势在于它很容易从JavaScript中使用，甚至只是一个带有表单提交的愚蠢网页。它也可以使用curl等工具从命令行轻松编写脚本。它几乎适用于任何语言，因为HTTP库，XML库和JSON库几乎无处不在，即使JSON解析器不可用，也很容易编写自己的。

编辑：我应该澄清一下，我指的是概念重量级SOAP是如何实现的，而不是重量级的，就原始数据而言。我认为原始数据量不那么重要（虽然如果你需要处理大量的小请求，它会快速增加），而它在概念上的重量级是非常重要的，因为这意味着有更多的地方在某些地方可能出错，可能存在不兼容性等等。

Answer 3

我同意第一张海报，但想补充一下。厚而薄的定义是相对的。对于像JSON或REST这样的传输，新兴的SOAP在“hello world”示例中表面看起来很重要。现在你可能已经知道什么使得SOAP和WS 2.0一般都是企业/强大的功能。 JSON不像WS 2.0那样安全。我没有听说SOAP被称为厚，但许多非XML坚果认为这些规格很重或很厚。要明确的是，我不是赞成或反对，因为两者都有自己的位置。 XML更冗长，更易读，因而“更厚”。最后一部分是有些人认为HTTP是一个持久的连接协议，因为像AJAX这样的新网络趋势而不是在大页面上提供服务。鉴于没有任何好处，连接开销很大。

总之，没有真正的理由除了有人想要调用SOAP / HTTP厚之外，它都是相对的。较少的标准是完美的，适用于所有情况。如果我不得不猜测一些聪明的网络开发人员认为他是如此聪明，谈论如何思考XML技术以及超级JSON是如何。每个人都有一个地方。

Answer 4

SOAP的信噪比太低。对于简单的对话，没有数据值的结构开销过多;并且需要太多显式配置（与隐式配置相比，如JSON）。

它不是那样开始的，但它最终成为标准委员会参与时好主意会发生什么的海报孩子。

Answer 5

首先，它在很大程度上取决于您的服务是如何实现的（即，您可以通过小心如何完成方法签名来减少有效负载）。

这就是说，不仅肥皂信封，而且消息本身在xml中可能更加庞大，而不是简化的二进制格式。只选择合适的类和成员名称可以减少很多......

请考虑以下返回一组东西的方法的序列化方法返回示例。如果您要返回重复数据（例如列表/集合/数组），只需为类/包装器和成员选择正确的[序列化]名称就可以对序列化soap请求/响应的详细程度产生重大影响。

简短名称：

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ShortIDName>
    <id>0</id>
    <name>foo 0</name>
  </ShortIDName>
  <ShortIDName>
    <id>1</id>
    <name>foo 1</name>
  </ShortIDName>
  <ShortIDName>
    <id>2</id>
    <name>foo 2</name>
  </ShortIDName>
  ...
</ArrayOfShortIDName>

长名称

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  ...
</ArrayOfThisClassHasALongClassNameIDName>

Answer 6

1 - XML模式是WSDL规范的关键部分，实际上非常大而复杂。实际上，使用将XML架构映射到编程语言构造之类的工具最终只支持部分XML架构功能。

2 - WS- *规范，例如WS-Security和WS-SecureConversation，又变得又大又复杂。它们几乎被设计成使得没有人比微软或IBM能够完全实现它们的资源更少。

Answer 7

我认为它“很厚”，因为包装和解包消息所涉及的开销相对较大（序列化和反序列化）。

考虑使用名为Add的Web方法的Web服务，该方法需要两个32位整数。调用者打包两个整数并接收一个整数作为答复。实际上只传输96比特的信息，添加SOAP数据包可能会在每个方向上增加大约3,000或更多的额外比特。增加30倍。

此外，与将序列化和反序列化为UTF-8（或其他）XML的相关性能相对较慢。不可否认，这些日子它很快，但它肯定不是微不足道的。

Answer 8

我认为主要是SOAP信封会为构造消息增加大量开销，特别是对于只有少量非深度结构化参数的简单请求的常见情况。将其与REST样式的Web服务进行比较，其中参数仅包含在URL查询中。

然后再加上WSDL的复杂性和典型的“企业”库实现......

为什么HTTP / SOAP被认为是“厚”

8 个答案: