我知道有很多关于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消息都没有将一对一映射到接收端的单个不同对象.

或者,我可能无所事事.

但是我在这里扫描信息的现实似乎与我在当地被告知的内容相矛盾.

解决方法:

我认为您会发现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版本就不会有太大的困难.不要试图以相反的方式做到这一点.