构建 Web 服务时，您可以采用两种方法：
大多数人都会选择阻力较小的道路，即REST。这意味着简单、易于开发、按照应有的方式使用 HTTP、充分利用缓存代理、更易于人类阅读的结果等。
SOAP另一端比 REST 更重量级，并且也有大量的支持规格 http://en.wikipedia.org/wiki/List_of_web_service_specifications。但由于它更加复杂（SOAP 曾经是 Simple Object Access Protocol 的缩写 – 事实证明……不是），所以 SOAP 并没有受到很多人的喜欢。
两种方法都有效，并且都有优点和缺点。
例如，SOAP 可以使用任何传输协议，而不仅仅是 HTTP(S)，在涉及安全性时，SOAP 提供更多选项，SOAP 提供可靠的消息传递等。另一方面，REST 允许许多不同类型的数据格式，REST 允许更好的数据格式。由于 JSON 格式而支持浏览器，REST 具有更好的性能等等。
我不打算讨论更多细节，因为您可以在网络上找到很多 SOAP 与 REST 的比较。我想强调的是，在某些情况下，一种方法比另一种方法效果更好，并且根据您的具体情况，您可以决定并选择实施哪一种.
EDIT:回答你的问题：
为什么使用 SOAP 或 REST？没有它们我们也能拥有网络服务吗？
那么，W3C 将 Web 服务定义为“旨在支持网络上可互操作的机器对机器交互的软件系统 http://en.wikipedia.org/wiki/Web_service".
好吧...这对于定义来说很好。但这不是 SOAP/REST 的定义，这个需求可以成功抛出通讯协议 http://en.wikipedia.org/wiki/Communications_protocol处理。
因此，基本上，只要支持“可互操作的机器对机器交互”，您就可以使用任何您想要的通信协议（甚至创建您自己的协议）来拥有 Web 服务。这也意味着 SOAP 或 REST 之外的其他东西（好吧……REST 不是一个协议，我只是在这里用它作为参考来证明我的观点……所以请耐心等待）。
但是您创建了一个 Web 服务，因为您希望一些客户使用您的服务。你的客户在狂野的西部（即网络：D），那里的人们讲 SOAP/REST。然后你过来说：“我们真的不喜欢我们店里的 SOAP 和 REST，我们喜欢 RPC、CORBA 和我们自己独特创建的“Bone Crusher 10000”协议之类的东西。如果你想和我们做生意，你就去学习“碎骨机10000”“。你的客户会说（扬起眉毛）”是啊啊啊啊啊啊啊啊啊……".
（我在这里假设您的协议不会是完全超越 SOAP/REST 的根本性协议：D）
因此，如果您不使用 SOAP/REST，您就会限制您的目标受众。例如，它就像英语。我不是以英语为母语的人，是吗？好吧，这并不重要，因为我们可以用英语交流。想尝试这个冰岛的 http://en.wikipedia.org/wiki/Icelandic_language？ 。我学习冰岛语时你会等我吗，因为这也不是我的母语？
正如我已经说过的，根据您的具体情况，您可以决定并选择要实施的内容，但是如果你远离已知的技术堆栈，你就会抛弃随之而来的东西：大量的经验、资源、工具和沟通选项.
作为最后一个示例，现在对 SOAP 协议有很多支持，您可以从 WSDL 文件开始非常轻松地生成客户端。和presto http://www.audioenglish.net/dictionary/presto.htm...您的客户可以与您的网络服务进行通信。 《Bone Crusher 10000》会这么简单吗？如果您编写工具、提供资源、支持等……是的！但这会花费你时间和金钱来创造一些东西已经被发明并且今天被广泛使用.
