我已阅读教程“web-service-php-mysql-xml-json”。
似乎一切正常。但是，为什么我们应该将 soap 用于 Web 服务呢？
【问题讨论】：
标签： web-services rest soap
在构建 Web 服务时，您可以采用两种方式：
大多数人选择阻力较小的路径，即REST。这意味着简单、易于开发、以应有的方式使用 HTTP、充分利用缓存代理、更易于人类阅读的结果等。
另一端的SOAP 比 REST 更重量级，并且还得到大量 specifications 的支持。但是因为它更复杂（SOAP 曾经是简单对象访问协议的首字母缩写词——后来被证明是……不是）SOAP 不被很多人喜欢。
这两种方法都有效，各有利弊。
例如，SOAP 可以使用任何传输协议，而不仅仅是 HTTP(S)，SOAP 在安全方面提供更多选择，SOAP 提供可靠的消息传递等。另一方面，REST 允许许多不同类型的数据格式，由于 JSON 格式，REST 可以更好地支持浏览器，REST 具有更好的性能等等等等。
我不打算详细介绍，因为您可以在 Web 上找到很多 SOAP 与 REST 的比较。我要强调的一点是，在某些情况下，一种方法比另一种效果更好，根据您的具体情况，由您决定并选择实施哪一种方法。
编辑：回答您的问题：
为什么要使用 SOAP 或 REST？没有它们我们可以有网络服务吗？
好吧，W3C 将 Web 服务定义为“a software system designed to support interoperable machine-to-machine interaction over a network”。
好的...这对定义来说很好。但这不是 SOAP/REST 的定义，这个需求可以成功地抛出一个communication protocol 来处理。
所以基本上你可以使用任何你想要的通信协议（甚至创建你自己的）来拥有一个 Web 服务，只要它支持“可互操作的机器对机器交互”。这也意味着 SOAP 或 REST 以外的其他东西（好吧……REST 不是协议，我只是在这里作为参考来证明我的观点……所以请耐心等待）。
但是您创建一个网络服务是因为您希望一些客户使用您的服务。而且您的客户在狂野的西部（即网络：D）那里，那里的人说 SOAP/REST。然后你过来说：“我们不喜欢在我们的商店里使用 SOAP 和 REST，我们喜欢 RPC、CORBA 和我们自己独特的“Bone Crusher 10000”协议之类的东西。如果你想做和我们做生意，你去学习“Bone Crusher 10000””。你的客户会说（扬起眉毛）“Yeaaaaaah righttttt.....”。
（我在这里假设您的协议不会是完全超越 SOAP/REST 的地面黑客：D）
因此，如果您不使用 SOAP/REST，您将限制您的目标受众。例如，它就像英语。我不是以英语为母语的人，你呢？好吧，这并不重要，因为我们能够用英语交流。想在Icelandic 试试这个吗？ .我学习冰岛语时你会等我吗，因为那也不是我的母语？
正如我已经说过的，由您决定并根据您的特定情况选择实施什么，但是如果您远离已知的技术堆栈，您就会抛弃随之而来的东西：丰富的经验、资源、工具和交流方式。
作为一个结束示例，现在有很多对 SOAP 协议的支持，您可以从 WSDL 文件开始非常轻松地生成客户端。并且presto...您的客户可以与您的网络服务进行通信。 “Bone Crusher 10000”会这么简单吗？如果您编写工具、提供资源、支持等……是的！但这将花费您时间和金钱来创建已经发明并在今天广泛使用的东西。
【讨论】：
user159088 在她/他的回答中提到的重要一点是“[...] 您可以从 WSDL 文件开始非常轻松地生成客户端 [...]”！
我想进一步详细说明：
您可以将 SOAP 与标准化的 WSDL 结合使用，这意味着了解该标准 (WSDL) 的人可以从中了解 Web 服务提供哪些操作以及如何交换数据。
这些知识可以用于 f.e.创建从 WSDL 文件生成类型安全绑定器类/对象的工具。您可以利用这些生成的类（以制作 RPC），而无需手动实现请求和对交换的数据进行编码/解析。
而对于 REST，交换数据的外观没有标准（如 WSDL 架构）。因此，您通常最终会自行解析数据。
第二点是 REST 主要使用 HTTP(s) 协议（它基于它）。它使用 HTTP(s) 协议的 CRUD 动词 (CREATE/READ/UPDATE/DELETE)。 SOAP 不依赖它，因此也可以与其他协议一起使用。
【讨论】：