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