鉴于目前 REST 框架/API 的成熟度，对于新的 SOA 项目，哪个应该是更好的选择 - 肥皂还是休息？
PS - 对不起，我是菜鸟，如果问错了问题，请告诉我！
【问题讨论】：
标签： web-services rest soap soa
这有点悬而未决。现在我一般对 REST 有点偏，但是 REST 和 SOAP 是两种不同的动物。 REST 更像是一种架构风格，而 SOAP 是一种描述的协议。话虽如此，我肯定写过很多 SOAP 接口。
我想指出的一件事是，使用 REST，您不受数据表示的限制，因此它可以是 XML、JSON、YAML 等。因此，您的数据可以更加轻量级。但是，对于 SOAP，您必须使用 XML。不过要明确考虑的一件事是如何使用这项服务。
一般来说，如果您的服务将被移动设备（Android、iOS、Windows Phone）使用，那么围绕 REST 的框架有很多，因此利用这些现有框架是明智的。如果您有较老的大型公司连接到此，他们可能会有现有的 SOAP 实现，因此他们会更容易访问 SOAP 服务。
不过，我想说的是，同时提供两者并没有那么遥不可及。如果您在 /api/v1/customers /api/v1/soap/customers/*。只要你的业务逻辑，如果有封装成不同的函数，那么SOAP和REST实现都可以调用。
我希望这对您有所帮助，但如果有很多关于技术的问题，请不要试图强迫您的用例适合该技术。您的技术选择应该来自用例。
【讨论】：
SOAP 是基于 xml 的协议，REST 是 ROA（Resource O面向A架构），而不是规范或标准。
Web 服务与 SOA 以及漂亮的 URL 与 REST
拥有 Web 服务并不意味着拥有 SOA 架构
这可能是我经常听到的关于 SOA 架构的最大误解之一。我看到许多开发人员认为，如果他们的架构中有一个或两个 Web 服务，他们会说他们的架构是 SOA 架构。我认为这是因为两个原因：1）“Web服务”和“面向服务”在命名上的相似之处让人认为它们是同一个东西； 2) 由于 Web 服务是实现 SOA 架构的最常见方式，这促使人们认为，当他们创建了一个 Web 服务时，他们的架构就是 SOA 架构。
SOA 架构的特点是组合独立服务，这些服务封装了业务功能并将其公开为服务，可以是 Web 服务、Windows 服务或任何其他形式的公开。 Web 的普及和 Web 开发技术的进步使得 Web 服务的创建变得更加容易，这使得 Web 服务成为实现 SOA 架构的一种选择，但是，SOA 架构中的服务定义并没有将 Web 服务置于任何关于 SOA 架构实现的特殊立场。
拥有漂亮的 URL 并不意味着你拥有 REST 架构风格
REST 架构风格是最近的另一个热门话题，因此也受到很多误解。 REST 为 Web 服务的实现带来了简单性，并在 Web 开发社区中广受欢迎。它与我们从 www 时代开始就熟悉的 HTTP 协议配合得很好。
REST 架构风格的一个特点是资源处于架构的中心，并且它们在 URL 中被精美地表示。 REST 为我们带来了漂亮的 URL，因此人们在 URL 和 REST 架构之间建立了联系。 Leonard Richardson 开发了一个成熟度模型，它可以告诉您的 API 或 RESTful 服务的级别到什么程度是 RESTful。
【讨论】：