为什么将SOAP用于Web服务?

| 我已经阅读了一个教程“ web-service-php-mysql-xml-json \”。 看来一切都很好。但是,为什么我们应该在Web服务中使用肥皂呢?     
已邀请:
        构建Web服务时,可以采用两种方法: 肥皂 休息 大多数人选择阻力较小的路径,即REST。这意味着简单,易于开发,按原意使用HTTP,充分利用缓存代理,更易理解的结果等。 另一端的SOAP比REST更为繁重,并且还受大量规范的支持。但是因为它更复杂(SOAP曾经是Simple Object Access Protocol的首字母缩写,事实证明是……NOT)SOAP不被很多人喜欢。 两种方法都起作用,并且都有优点和缺点。 例如,SOAP不仅可以使用HTTP(S),还可以使用任何传输协议;考虑到安全性,SOAP提供了更多选择; SOAP提供了可靠的消息传递等。另一方面,REST允许许多不同类型的数据格式,REST允许更好的数据格式。由于JSON格式支持浏览器,REST具有更好的性能等,等等。 由于您可以在网络上找到很多SOAP与REST的比较,因此我不再赘述。我要强调的事实是,在某些情况下,一种方法的效果要优于另一种方法,并且要根据您的具体情况决定并选择实施哪种方法。 编辑:要回答您的问题:   为什么要使用SOAP或REST?没有他们,我们可以拥有网络服务吗? 嗯,W3C将Web服务定义为“一种软件系统,旨在支持通过网络进行互操作的机器对机器交互”。 好的,这很适合定义。但这不是SOAP / REST的定义,可以成功地通过通信协议来处理此要求。 因此,基本上只要您支持“可互操作的机器对机器交互”,就可以使用所需的任何通信协议(甚至创建自己的通信协议)来提供Web服务。这也意味着除SOAP或REST之外的其他东西(好的... REST不是协议,我只是在这里用它作为参考来证明我的观点...所以请耐心等待)。 但是您创建Web服务是因为您希望某些客户端使用您的服务。您的客户就在狂野的西部(即网路:D)那里,那里的人们讲SOAP / REST。你会说:“我们绝对不喜欢我们商店里的SOAP和REST,我们喜欢RPC,CORBA之类的东西,还喜欢我们自己独特的创作“ Bone Crusher 10000 \”协议。如果您想与我们开展业务,您将学习“骨头破碎机10000”。您的客户会说(扬起眉毛)“ Yeaaaaah righttttt ..... \”。 (我在这里假设您的协议不会完全超越SOAP / REST:D) 因此,如果您不使用SOAP / REST,则会限制目标受众。例如英语。我不是说英语的人,对吗?嗯,这并不重要,因为我们能够用英语交流。想尝试冰岛语吗? 。当我学习冰岛语时,您是否会等我,因为那也不是我的母语? 正如我已经说过的那样,您可以根据自己的具体情况来确定和选择实现的方法,但是如果您离开已知的技术栈,则会丢弃随之而来的东西:大量的经验,资源,工具和通信选项。 作为结束示例,今天对SOAP协议有很多支持,您可以从WSDL文件开始非常轻松地生成客户端。并...您的客户可以与您的Web服务进行通信。使用“ Bone Crusher 10000”会像这样轻松吗?如果您编写工具,请提供资源,支持等...是的!但这将花费您时间和金钱来创建已经发明并且如今被广泛使用的东西。     
user159088在他/他的回答中提到的一个重要点是\“ [...],您可以很容易地从WSDL文件开始生成客户端!” 我想进一步阐述一下: 您可以将SOAP与WSDL结合使用,WSDL是标准化的,这意味着知道标准(WSDL)的人可以从中学习Web服务提供的操作以及如何交换数据。 可以将这些知识用于创建工具来从WSDL文件中生成类型安全的绑定器类/对象。您可以使用这些生成的类(用于制作RPC),而无需手动实现请求以及对交换的数据进行编码/解析。 对于REST,没有关于交换数据外观的标准(如WSDL模式)。结果,您经常最终会自行解析数据。 第二点是,REST主要与HTTP协议(基于它)一起工作。它使用HTTP协议的CRUD动词(CREATE / READ / UPDATE / DELETE)。 SOAP不依赖于它,因此也可以与其他协议一起使用。     

要回复问题请先登录注册