我知道有很多关于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消息都没有将一对一映射到接收端的单个不同对象。
或者，我可能无所事事。
但是我在这里扫描信息的现实似乎与我在当地被告知的内容相矛盾。
答案 0 :(得分：5)
我不买SOAP。
Don Box的简单对象访问协议的原始愿景现在变得非常简单。它变得臃肿，由委员会混乱设计。
抛弃膨胀库的所有其他依赖关系，你手上可能会有一些混乱。
工具供应商喜欢SOAP，但我对其他人的看法并不多。
答案 1 :(得分：3)
我认为您会发现PHP开发人员更倾向于使用RESTful接口。这是2003年关于它的文章。
http://onlamp.com/pub/a/php/2003/10/30/amazon_rest.html
RESTful接口是一种日益增长的现象，如果你需要吸引开发人员加入你的平台，那么如果你抓住这个浪潮就会更容易。
话虽如此，有没有理由不支持多个接口？这在没有专属受众的Web服务中相当常见。您可以支持您的遗留模型，干净的RESTful模型和SOAP / WSDL模型。然后在6个月到一年后进行盘点，看看哪种型号最受欢迎且支持最少。
当涉及到让外部人员更容易访问网站时，REST的使用范围更广泛。至于保存您的项目，SOAP可能会这样做，因为它在界面设计中需要一定的严谨性，但是REST也是如此。如果这是一个关键标准，那么您应该放弃手工编码的XML并使用可以作为REST和SOAP实现的高级接口设计。
我知道有些人认为SOAP和REST是根本不同的方法，但如果你采用RESTful方法进行接口设计，那么创建SOAP版本就不会有太大的困难。不要试图以相反的方式做到这一点。
答案 2 :(得分：1)
这是classic, hilarious, debunking of SOAP - The "S" stands for Simple"。我搬进的社区完全转换为REST。
答案 3 :(得分：0)
如果您浏览网络上的RESTful接口，您会发现SOAP几乎普遍避免。 SOAP是一个如此复杂的野兽，它有效地锁定了没有现有SOAP包的语言，因为没有人会自己实现它。另一方面，原始XML在这一点上非常普遍，如果有必要，并不难在内部实现。