网络编程：SOAP 与 DIY 编组与 XML 库？答案

【问题标题】：Network programming: SOAP vs DIY marshalling with XML library?网络编程：SOAP 与 DIY 编组与 XML 库？
【发布时间】：2009-10-17 17:49:04
【问题描述】：

我知道已经有很多关于 SO 的讨论，包括 SOAP、膨胀、XML 和 REST 等替代机制。

情况是这样的。一个新的团队成员真的在谈论基于手工实现协议的难度的 SOAP。他推荐使用 gSOAP（项目全部使用 C++。）他说的是 WSDL 之类的东西可以清理大量杂乱的手工编码的 C++。

现在，我正在处理大多数使用基于 XML 的文本消息和 expat XML 库的网络。所以我有一些与修改消息格式或添加参数列表相关的编程工作（不多）。在发送端，我打包一个 XML 请求并通过一个普通的旧 TCP 套接字发送它。在接收方，我使用 DOM 或 SAX 解析 XML。等等。到目前为止它工作得很好。 XML 消息非常紧凑，平均最多只有几百个字符。我理解这些消息中的每一项。

我们希望使用 PHP 编码的网站可以访问产品的一部分（服务器）。这在一定程度上推动了这个想法，即 SOAP 接口对于脚本编写者来说将“更容易”。这个项目的每个人都相信 SOAP 是他们的救赎。

我认为像 gSOAP 这样的新大型库的引入对成熟项目的发展势头具有极大的破坏性。

我想知道的是，是否有一种不同且更紧凑的方式来执行 SOAP 为我们提供的功能。以及如何平衡 gSOAP 或其他 SOAP 工具的主张，使开发生活更轻松与严峻的现实。

IE，有人告诉我，WSDL 比使用 XML 库手动编码 C++ 更好、更容易、更熟练等。它将 C++ 对象的语义直接放入网络消息的声明中。问题是，我定义的许多 XML 消息在接收端并没有一对一地映射到单个不同的对象。

或者，我可能什么都不担心。

但是当我在这里扫描消息时，现实似乎与我在当地得到的说法相矛盾。

【问题讨论】：

我可以说您非常关心 SOAP 的开销/膨胀吗？并试图找出如何在没有这些缺点的情况下实现 SOAP？
在此之前我从未考虑过 SOAP。团队中的新人推荐 SOAP 是因为两个明显的原因：1) 他已经使用过它；2) 他不喜欢手动编码 XML 代码的想法，这种代码会撕裂字符串并将它们解析为数据值。跨度>
如果你想开辟一个渠道供其他人使用，你不必使用 SOAP，但最好是已经存在并适合你需要的东西。
我非常同意你的观点，特别是因为你已经有了一个可以工作的非 SOAP 系统。但是您是否考虑过不解析字符串，而是将数据中的all结构表示为XML 结构？这并不总是可行的，但如果你能做到，它可能是一个更好的选择。

标签： c++ rest soap wsdl gsoap

【解决方案1】：

我不买 SOAP。

Don Box 对简单对象访问协议的最初设想现在一点也不简单。它变得臃肿，由委员会设计的烂摊子。

加上对臃肿库的所有额外依赖项，您可能会遇到麻烦。

工具供应商喜欢 SOAP，但我看不到其他人太多。

【讨论】：

感谢您的快速回复。它验证了我的猜想。我正在寻找具体的谈话要点。现在我们（在这个项目上）处于挥手模式。
它最初是作为每个平台进行通信的协议。目前它是一只肥羊，许多框架/解决方案仍然提倡。好吧，我也不热衷于此。

【解决方案2】：

我想你会发现 PHP 开发者更喜欢 RESTful 接口。这是一篇关于它的 2003 年文章。

http://onlamp.com/pub/a/php/2003/10/30/amazon_rest.html

RESTful 接口是一种日益增长的现象，如果您需要吸引开发人员加入您的平台，那么赶上潮流会更容易。

话虽如此，您是否有充分的理由不能支持多个接口？这在没有固定受众的 Web 服务中相当常见。您可以支持您的遗留模型、干净的 RESTful 模型和 SOAP/WSDL 模型。然后在 6 个月到 1 年后进行评估，看看哪种模型最受欢迎且支持最少。

在使网站更容易被外人访问时，REST 具有更广泛的用途。就保存您的项目而言，SOAP 可能会这样做，因为它需要在接口设计中进行一定程度的严格性，但是对于 REST 也可以这样说。如果这是一个关键标准，那么您可能应该放弃手动编码的 XML，而采用可以作为 REST 和 SOAP 实现的高级接口设计。

我知道有些人认为 SOAP 和 REST 是根本不同的方法，但是如果您采用 RESTful 方法进行界面设计，那么创建 SOAP 版本应该不会有很大困难。不过不要试图反其道而行之。

【讨论】：

Michael，我正在考虑您的帖子“答案”，尽管此线程实际上只是一个开始，以便评估有关 SOAP 的声明。到目前为止，合唱似乎是一个响亮的“这将比你被告知的要困难得多”。感谢您的具体建议。

【解决方案3】：

这是classic, hilarious, debunking of SOAP - The "S" stands for Simple"。我搬入的社区完全转换为 REST。

【讨论】：

【解决方案4】：

如果您查看网络上的 RESTful 接口，您会注意到几乎普遍避免 SOAP。 SOAP 是如此复杂，以至于它有效地锁定了没有现有 SOAP 包的语言，因为没有人会自己实现它。另一方面，原始 XML 在这一点上是相当普遍的，如果需要，在内部实现并不难。

【讨论】：