为什么HTTP/SOAP被认为是"厚"

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

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

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

SOAP被设计为足够抽象以使用除HTTP之外的其他传输.这意味着,除其他外,它没有利用HTTP的某些方面(主要是REST和URL和方法的使用,例如PUT /customers/1234或GET /customers/1234).

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

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

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

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是如何,而不是重量,它是根据原始数据量.我认为原始数据量不那么重要(虽然如果你需要处理大量的小请求,它会快速增加),而它在概念上的重量级是非常重要的,因为这意味着有更多的地方在某些地方可能出错,可能存在不兼容等问题.

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

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

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

它并没有这样开始,但最终成为标准委员会参与时好主意发生的事情的典型代表.