SOA体系结构风格基于企业业务体系结构的功能分解，并引入了两个高级抽象：企业业务服务和业务流程...另一方面，REST是一组表达为面向资源的体系结构（ROA）的体系结构指南。 ）。 ROA基于资源的概念； ... 不可能使用真正的REST构建SOA系统。
和
REST Web服务方法是仅将REST作为一种通信技术来构建SOA的方法。 在这种情况下，将使用SOA样式分解定义服务，并利用基于REST的Web服务作为传输。
您能否详细解释一下最后的报价？ 他们是说RESTful Web服务与REST或仅与REST有什么不同吗？ 使用REST作为通信技术意味着什么？ “基于REST的Web服务被用作传输”是什么意思？
由于您无法使用纯REST构建SOA（ 如带有纯名词的句子 ），我想知道在适合REST的地方而不适合不适合的地方安排应用程序部件的正确方法是什么？ 我应该将REST部分与非REST部分分开吗？ 非REST部分应如何彼此之间以及与REST部分进行通信？
是的，文章指出REST与“ RESTful Web服务”有所不同。
作者将REST与“名词”（而非动词）或Web的“ DBMS”进行了比较。 我可以不使用动词写一个句子吗？ 否。我可以仅使用DBMS来构建系统吗？ 不能。以同样的方式，不能仅使用REST体系结构原理来构建系统。 在大多数系统中，REST语义最终会崩溃。 本文中给出的一个示例是何时需要消息传递解决方案。
我认为作者是说“ RESTful Web服务”是整个句子，而REST只是名词。 在“ RESTful Web服务”中，可以使用在纯REST组件的实现中经常使用的类似技术和编程样式来实现不具有REST语义的系统部分（基本上不是CRUD的任何部分）。
“ REST作为一种通信技术”基本上仅意味着将服务的传输实现限制为HTTP。 大多数Web服务框架为传输提供了多种选择（例如WCF可以通过HTTP执行SOAP，或者使用共享内存，或者使用TCP进行不带HTTP的网络服务）。 REST避开了这种灵活性，转而追求简单性。 根据我对引用的文章的解释，“ RESTful Web服务”将完全基于HTTP。
总而言之，REST只是一种建筑风格。 仅使用一种架构样式就不可能构建任何值得注意的技术解决方案。 因此，“ RESTful Web服务”是在适当的地方利用REST体系结构原理的简单Web服务。
再说一次，这不是我的意见，只是我对本文所说内容的解释。
我认为纯“ REST”终结点（CRUD）与更多面向行为/服务的终结点之间不需要任何特殊的分隔，事实上，任何给定的URL应该是一个或另一个，而您可能会发现自己不想在相同的基本URL下混合使用两种样式。 例如，如果您有一个REST端点来检索id = 1234的用户帐户的详细信息：
/users/id/1234
并且您要实现“验证电子邮件”工作流程（出于论点的考虑，该工作流程并未实现为REST服务），然后为您的验证电子邮件工作流程/服务选择一个与REST风格/ users / API不冲突的URL。 不要试图做这样的事情：
/users/id/1234/verifyEmail?securityToken=XXXX
但是，宁愿为此端点创建一个全新的URL：
/verifyEmail/userId/1234?securityToken=XXX
这些准则在很大程度上是任意的 ：重要的是，以一种使其他程序员有意义的方式设计服务，因为这些人将使用您的服务。 与软件设计的其他任何方面一样，“单一职责负责人”将带给您很长的路要走。 每个基本URL只能做一件事！
如引言中所述，作为应用程序引擎（HATEOAS）约束的超媒体是鲜为人知的约束之一，因此很少正确实现。 不论是否违反超媒体约束，很多服务都声称是RESTful的事实使他很烦恼，Fielding [29]非常清楚超媒体是一项基本要求，但是由于REST一词被广泛滥用，因此在社区寻找替代术语，例如Hypermedia API，以表示真正的RESTful服务
REST体系结构具有定义明确的约束，您可以在这里找到： http : //www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
据我所知，RESTful一词来自理查森成熟度模型。 http://martinfowler.com/articles/richardsonMaturityModel.html我不知道原始文章在哪里，但据我所知这是胡说八道，就像您应该调用每个API REST一样，至少可以实现一个约束，您应该只调用满足每个REST约束的API的RESTful。 Fielding清楚地表明，只有满足所有约束的API才被视为REST，而不是简单的Web API的API被视为REST API。 可悲的是，对于REST一无所知的开发人员都过度使用了REST和RESTful单词。 他们中的大多数甚至都不知道REST约束存在。 对于他们来说，REST只是CRUD和URI设计。 只需检查一下有关REST的问题，其中99％就是这样。 当我回答与REST有关的问题时，我从中得到的评分甚至更有趣。因此，为了避免造成混淆和误解，我们现在构建Hypermedia API，因此只要人们不开始使用此词，我们就可以活在零头。 ...
大多数问题我都说不通。 我在这里将REST和SOAP与许多人进行了比较， 代表性状态传输（REST）和简单对象访问协议（SOAP）也许您找到了问题的答案。
非REST部分应如何彼此之间以及与REST部分进行通信？
如果您说微服务是按应用程序部分划分的，那么通常是ofc。 SOA和REST微服务可以简单地通过向彼此发送HTTP和SOAP消息来彼此通信。 如果您没有遗留的SOAP系统，则我建议仅开发REST服务，因为SOAP是有状态的，因此它的伸缩性不如REST。