SOA - 微服务:使用API​​ REST或SOAP

Question

我面临着一个巨大的困境:在我的公司,我们正致力于微服务架构并转向完整的SOA生态系统.

一些顾问和开发人员表示,SOAP for web服务会更好,因为它允许为所有开发团队指定并提供经过验证的格式.我害怕使用SOAP,最后我们会受到限制.

根据您的经验,对于SOA /微服务架构,使用SOAP或REST API会更好吗？

在此先感谢您的有用反馈.

Answer 1

根据您在问题中提供的信息选择体系结构样式很困难,因为您没有解释您拥有的业务需求或约束类型.你也没有解释这些服务的用途.

我一直在使用SOAP和REST一段时间,我可以告诉你,两者都有adv/dis.但是,我将尝试给出我将选择一个而不是另一个的原因和场景,而不是列举那些.

休息

1. 如果服务将由Web浏览器互联网应用程序,移动应用程序(当处理能力为"低"时)消耗,我将选择REST,因为通信是以json格式进行的,这对javascript技术以及处理和解析时间更友好小于XML.
2. 当服务将数据公开为简单API的一部分,允许用户访问CRUD操作,或者流程中涉及的业务逻辑不多.如果我必须构建一个公共API,我也会选择REST.
3. 如果时间有效,REST的实现比SOAP更简单.由于没有标准,您不需要签订合同.有一些最佳实践,但最后你可以根据需要使用HTTP动词并以你喜欢的方式创建URI样式,但是具有这么大的灵活性会让你在某些时候开始做一种RPC API而不是资源API(记住REST更多关于资源).
4. 如果您的服务的目的是在网页应用程序上公开信息,请利用浏览器中http GET动词提供的缓存.
5. 从开发人员的角度来看,这一点很重要,构建这些服务的速度更快.您只需要知道一个支持REST的框架,例如JAX-RS,Spring REST,Jersey和一些JSON概念.学习曲线也较小.
6. 它是一种轻量级的传输信息,速度更快,因为它不需要大量处理.

肥皂

1. 拥有定义服务内部通信的合同,您将与此合同挂钩,您的客户也必须遵守此合同.本合同的任何变更都将影响您的所有客户.您必须始终记录必须用于操作的合同.
2. 有一些有趣的标准可以作为WS-Interoperability,WS-addressing,WS-security在系统集成中工作,所以基本上是一种技术,它有几个标准,使协议阶段更容易,而不是总是实现.
3. 如果你想拥有不同类型的客户端,可以使用不同的传输层smtp,http.
4. 传输二进制数据MTOM/XOP或SwA的良好标准.如果喜欢这个,则在PUT请求的主体中发送字节.
5. 更好地定义安全性和完整性,许多选项来自标准,通常在REST中使用的更多是OAuth.
6. 从开发人员的角度来看,这需要更多的时间来学习,而且您至少需要具备XSD,XPath,WSDL和其他概念的基本知识.在某些情况下遵循标准并不总是那么容易.你有很好的工具和框架来构建它们JAX/WS,Spring-ws,CXF.

回答你的问题并想到一个试图标准化IT基础设施的中小型公司,我会选择SOAP,因为它在所有领域都有更成熟的工具支持.就个人而言,我喜欢SOAP:故障消息,SOAP提供的业务操作的RPC样式.假设您的微服务与特定领域无关,我认为某种ESB可以帮助您管理整个基础架构并设置业务规则.有时,人们可能会认为SOAP过度设计了解决方案.但是,我认为这是一个已经进入市场一段时间的标准.