我知道已经有很多关于 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 消息在接收端并没有一对一地映射到单个不同的对象。
或者，我可能什么都不担心。
但是，当我在这里扫描消息时，现实似乎与我在当地被告知的内容相矛盾。