我面临着一个大难题:在我的公司，我们正在研究微服务架构并切换到完整的 SOA 生态系统。
一些顾问和开发人员表示，将 SOAP 用于 Web 服务会更好，因为它允许指定并向所有开发人员团队提供经过验证的格式。我害怕使用 SOAP 我们最终会受到限制。
根据您的经验，对于 SOA/微服务架构，使用 SOAP 还是 REST API 会更好吗？
预先感谢您提供有用的反馈。
很难根据您在问题中提供的信息来选择架构风格，因为您没有解释您拥有的业务需求或约束类型。你也没有解释这些服务的用途。
我已经使用 SOAP 和 REST 一段时间了，我可以告诉你，两者都有 adv/dis。但是，我不会一一列举，而是尝试给出我会选择其中一个的原因和场景。
休息
如果服务将由 Web 浏览器互联网应用程序、移动应用程序(当处理能力“低”时)使用，我将选择 REST，因为以 json 格式进行通信，这对 javascript 技术和处理和解析时间更加友好小于 XML。 当服务将数据作为简单 API 的一部分公开时，允许用户访问以执行 CRUD 操作，或者当流程中不涉及太多业务逻辑时。如果我必须构建一个公共(public) API，我也会选择 REST。 如果时间紧迫，REST 的实现比 SOAP 更简单。由于没有标准，您不需要签订契约(Contract)。有一些最佳实践，但最后您可以根据需要使用 HTTP 动词并以您喜欢的方式创建 URI 样式，但是拥有如此大的灵活性将使您在某个时候开始做一种 RPC API 而不是资源API(请记住 REST 更多关于资源)。 如果您的服务的目的是在网页应用程序上公开信息，则利用浏览器中 http GET 动词提供的缓存。 从开发人员的角度来看，这总是很重要的，构建此类服务会更快。您只需要了解一个支持 REST 的框架，例如 JAX-RS、Spring REST、Jersey 和 JSON 的一些概念。学习曲线也更小。 它是一种轻量级的传输信息形式，速度更快，因为它不需要大量处理。 肥皂
拥有定义服务内通信的契约(Contract)，您将被绑定(bind)到此契约(Contract)，您的客户也必须遵守它。本契约(Contract)的任何更改都将影响您的所有客户。您必须始终记录您的运营必须使用哪些契约(Contract)。 有一些有趣的标准可以在系统集成中工作，如 WS-Interoperability、WS-addressing、WS-security，所以基本上是一种具有多个标准的技术，这些标准使协议(protocol)阶段更容易，而不总是实现。 如果您想拥有不同类型的客户端，可以与不同的传输层 smtp、http 一起使用。 传输二进制数据 MTOM/XOP 或 SwA 的良好标准。如果更喜欢这个发送 PUT 请求正文中的字节。 更好地定义安全性和完整性，来自标准的很多选项，通常在 REST 中使用较多的是 OAuth。 从开发人员的角度来看，这将需要更多的时间来学习，而且您至少需要对 XSD、XPath、WSDL 和其他概念有非常基本的了解。在某些情况下，遵循标准并不总是那么容易。你有很好的工具和框架来构建它们 JAX/WS、Spring-ws、CXF。 回答您的问题，并在尝试标准化 IT 基础架构的中小型公司中思考，我会选择 SOAP，因为它在所有领域都有更成熟的工具支持。就个人而言，我喜欢 SOAP:fault 消息，这是 SOAP 提供的用于业务操作的 RPC 样式。假设您的微服务与特定领域无关，我认为拥有某种 ESB 可以帮助您管理整个基础架构并设置您的业务规则。有时，人们可能会认为 SOAP 过度设计了解决方案。但是，我同意这个想法，因为它是市场上已有一段时间的标准。