REST 与 RESTful Web 服务
REST vs RESTful Web Service
SOA architectural style is based on a functional decomposition of
enterprise business architecture and introduces two high-level
abstractions: enterprise business services and business processes...
REST, on another hand, is a set of architectural guidelines expressed
as Resource-Oriented Architecture (ROA). ROA is based upon the concept of resources;
... it is impossible to build an SOA system using true REST.
和
The REST Web Service approach is an approach for using REST purely as
a communication technology to build SOA. In this case, services are
defined using SOA style decomposition and REST-based Web Services
are leveraged as a transport.
您能否更详细地解释一下最后的报价？他们的意思是 RESTful Web 服务与 REST 有什么不同，或者不仅仅是 REST 还是什么？他们将 REST 用作通信技术是什么意思？ “基于 REST 的 Web 服务被用作传输”是什么意思？
更新：tonicsoft 回答
由于您不能使用纯 REST 构建 SOA（喜欢纯名词的句子）我想知道安排应用程序部件的正确方法是什么哪里 REST 合适，哪里不合适？我应该将 REST 部分与非 REST 部分分开吗？非 REST 部分应该如何相互通信以及如何与 REST 部分通信？
是的，文章指出 REST 与 "RESTful web services" 有所不同。
作者将 REST 比作 "nouns" 而不是动词，或者网络的 "DBMS"。我可以不用动词写一个句子吗？不可以。我可以只使用 DBMS 构建系统吗？不可以。同样，不能只使用 REST 架构原则来构建系统。在大多数系统中，REST 语义最终会崩溃。文章中给出的一个示例是当需要消息传递解决方案时。
我认为作者是在说 "RESTful web service" 是整个句子，而 REST 只是名词。在 "RESTful web service" 中，系统中没有 REST 语义的部分（基本上不是 CRUD 的任何东西）可以使用在纯 REST 组件实现中常见的类似技术和编程风格来实现。
"REST as a communications technology" 基本上只是意味着将服务的传输实现限制为 HTTP。大多数 Web 服务框架为传输提供了多种选择（例如，WCF 可以通过 HTTP 执行 SOAP，或使用共享内存，或 TCP 用于没有 HTTP 的网络服务）。 REST 避开了这种灵活性，而倾向于简单性。根据我对引用文章的解释，"RESTful web service" 将完全基于 HTTP。
总而言之，REST 只是一种架构风格。仅使用一种架构风格是不可能构建任何值得注意的技术解决方案的。因此，"RESTful web service" 是一个简单的 Web 服务，它在适当的地方利用了 REST 架构原则。
再次声明，这不是我的观点，这只是我对文章内容的解释。
如何将纯 REST 操作与其他操作分开 "RESTful web service"
我认为在纯 "REST" 端点 (CRUD) 和更面向 behavioural/service 的端点之间不需要任何特定的分离，除了任何给定的 URL 应该非此即彼，您可能会发现您不想在同一个基础 URL 下混合使用这两种样式。例如，如果您有一个 REST 端点用于检索 id=1234 的用户帐户的详细信息：
/users/id/1234
并且您想实施一个 "verify email" 工作流程（出于争论的原因，它没有作为 REST 服务实施），然后为您的验证电子邮件 workflow/service 选择一个 URL '与 REST 风格 /users/ API 冲突。不要被诱惑做这样的事情：
/users/id/1234/verifyEmail?securityToken=XXXX
但是，更愿意为此端点创建一个全新的 URL：
/verifyEmail/userId/1234?securityToken=XXX
这些指导方针在很大程度上是随意的：重要的是设计您的服务时要让其他程序员理解，因为这些人将使用您的服务。与任何其他软件设计一样，单一职责原则会让你走得更远。每个基地URL应该只做一件事！
As mentioned in th e introduction, the H ypermedia as the E
ngine of A pplication S tate (HATEOAS) constraint is one of
the least understood constraints, and thus seldom implemented
correctly. Annoyed by the fact that a lot of services claim
to be RESTful regardless of violating the hypermedia
constraint, Fielding [29] made it very clear that hypermedia is
a fundamental requirement but since the term REST is so widely
misused, there are e fforts in the community to look for an
alternative term, such as Hypermedia API , to denote truly
RESTful services
- http://www.ws-rest.org/2012/proc/a4-2-lanthaler.pdf
- http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf
- http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
REST 架构具有明确定义的约束，您可以在此处找到：http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
据我所知，RESTful 一词来自理查森成熟度模型。 http://martinfowler.com/articles/richardsonMaturityModel.html 我不知道原来的文章在哪里，但据我所知这是一些废话，你应该调用每个 API REST，它至少满足一个约束，你应该仅调用 RESTful 满足每个 REST 约束的那些 API。 Fielding 多次明确表示，只有满足所有约束的 APIs 才被认为是 REST，而 APIs 不是简单的 web APIs，但不是 REST APIs .遗憾的是，REST 和 RESTful 词都被对 REST 一无所知的开发人员滥用。他们中的大多数甚至不知道 REST 约束的存在。对他们来说 REST 只是 CRUD 和 URI 设计。只需查看有关 REST 的 SO 问题，99% 都是那种东西。更有趣的是，当我回答与 REST 相关的问题时，我从他们那里得到了减分...所以为了避免混淆和误解，我们现在构建超媒体 APIs，所以只要人们不开始，我们就可以生活在一块也用这个词...
我无法理解大多数问题。我在这里与许多人比较了 REST 和 SOAP Representational state transfer (REST) and Simple Object Access Protocol (SOAP) 也许您会找到问题的答案。
How not-REST part should comunicate among each other and with REST
parts?
如果您指的是 microservices 应用程序部件，那么就是 ofc。 SOA 和 REST 微服务可以简单地通过相互发送 HTTP 和 SOAP 消息来相互通信。如果您没有遗留的 SOAP 系统，那么我建议只开发 REST 服务，因为 SOAP 是有状态的，因此它的扩展性不如 REST。
SOA architectural style is based on a functional decomposition of enterprise business architecture and introduces two high-level abstractions: enterprise business services and business processes... REST, on another hand, is a set of architectural guidelines expressed as Resource-Oriented Architecture (ROA). ROA is based upon the concept of resources; ... it is impossible to build an SOA system using true REST.
和
The REST Web Service approach is an approach for using REST purely as a communication technology to build SOA. In this case, services are defined using SOA style decomposition and REST-based Web Services are leveraged as a transport.
您能否更详细地解释一下最后的报价？他们的意思是 RESTful Web 服务与 REST 有什么不同，或者不仅仅是 REST 还是什么？他们将 REST 用作通信技术是什么意思？ “基于 REST 的 Web 服务被用作传输”是什么意思？
更新：tonicsoft 回答
由于您不能使用纯 REST 构建 SOA（喜欢纯名词的句子）我想知道安排应用程序部件的正确方法是什么哪里 REST 合适，哪里不合适？我应该将 REST 部分与非 REST 部分分开吗？非 REST 部分应该如何相互通信以及如何与 REST 部分通信？
是的，文章指出 REST 与 "RESTful web services" 有所不同。
作者将 REST 比作 "nouns" 而不是动词，或者网络的 "DBMS"。我可以不用动词写一个句子吗？不可以。我可以只使用 DBMS 构建系统吗？不可以。同样，不能只使用 REST 架构原则来构建系统。在大多数系统中，REST 语义最终会崩溃。文章中给出的一个示例是当需要消息传递解决方案时。
我认为作者是在说 "RESTful web service" 是整个句子，而 REST 只是名词。在 "RESTful web service" 中，系统中没有 REST 语义的部分（基本上不是 CRUD 的任何东西）可以使用在纯 REST 组件实现中常见的类似技术和编程风格来实现。
"REST as a communications technology" 基本上只是意味着将服务的传输实现限制为 HTTP。大多数 Web 服务框架为传输提供了多种选择（例如，WCF 可以通过 HTTP 执行 SOAP，或使用共享内存，或 TCP 用于没有 HTTP 的网络服务）。 REST 避开了这种灵活性，而倾向于简单性。根据我对引用文章的解释，"RESTful web service" 将完全基于 HTTP。
总而言之，REST 只是一种架构风格。仅使用一种架构风格是不可能构建任何值得注意的技术解决方案的。因此，"RESTful web service" 是一个简单的 Web 服务，它在适当的地方利用了 REST 架构原则。
再次声明，这不是我的观点，这只是我对文章内容的解释。
如何将纯 REST 操作与其他操作分开 "RESTful web service"
我认为在纯 "REST" 端点 (CRUD) 和更面向 behavioural/service 的端点之间不需要任何特定的分离，除了任何给定的 URL 应该非此即彼，您可能会发现您不想在同一个基础 URL 下混合使用这两种样式。例如，如果您有一个 REST 端点用于检索 id=1234 的用户帐户的详细信息：
/users/id/1234
并且您想实施一个 "verify email" 工作流程（出于争论的原因，它没有作为 REST 服务实施），然后为您的验证电子邮件 workflow/service 选择一个 URL '与 REST 风格 /users/ API 冲突。不要被诱惑做这样的事情：
/users/id/1234/verifyEmail?securityToken=XXXX
但是，更愿意为此端点创建一个全新的 URL：
/verifyEmail/userId/1234?securityToken=XXX
这些指导方针在很大程度上是随意的：重要的是设计您的服务时要让其他程序员理解，因为这些人将使用您的服务。与任何其他软件设计一样，单一职责原则会让你走得更远。每个基地URL应该只做一件事！
As mentioned in th e introduction, the H ypermedia as the E ngine of A pplication S tate (HATEOAS) constraint is one of the least understood constraints, and thus seldom implemented correctly. Annoyed by the fact that a lot of services claim to be RESTful regardless of violating the hypermedia constraint, Fielding [29] made it very clear that hypermedia is a fundamental requirement but since the term REST is so widely misused, there are e fforts in the community to look for an alternative term, such as Hypermedia API , to denote truly RESTful services
- http://www.ws-rest.org/2012/proc/a4-2-lanthaler.pdf
- http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf
- http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
REST 架构具有明确定义的约束，您可以在此处找到：http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
据我所知，RESTful 一词来自理查森成熟度模型。 http://martinfowler.com/articles/richardsonMaturityModel.html 我不知道原来的文章在哪里，但据我所知这是一些废话，你应该调用每个 API REST，它至少满足一个约束，你应该仅调用 RESTful 满足每个 REST 约束的那些 API。 Fielding 多次明确表示，只有满足所有约束的 APIs 才被认为是 REST，而 APIs 不是简单的 web APIs，但不是 REST APIs .遗憾的是，REST 和 RESTful 词都被对 REST 一无所知的开发人员滥用。他们中的大多数甚至不知道 REST 约束的存在。对他们来说 REST 只是 CRUD 和 URI 设计。只需查看有关 REST 的 SO 问题，99% 都是那种东西。更有趣的是，当我回答与 REST 相关的问题时，我从他们那里得到了减分...所以为了避免混淆和误解，我们现在构建超媒体 APIs，所以只要人们不开始，我们就可以生活在一块也用这个词...
我无法理解大多数问题。我在这里与许多人比较了 REST 和 SOAP Representational state transfer (REST) and Simple Object Access Protocol (SOAP) 也许您会找到问题的答案。
How not-REST part should comunicate among each other and with REST parts?
如果您指的是 microservices 应用程序部件，那么就是 ofc。 SOA 和 REST 微服务可以简单地通过相互发送 HTTP 和 SOAP 消息来相互通信。如果您没有遗留的 SOAP 系统，那么我建议只开发 REST 服务，因为 SOAP 是有状态的，因此它的扩展性不如 REST。