问题是理论上的。我发现面向资源的体系结构和面向服务的体系结构之间的区别类似于面向对象编程和过程编程之间的区别。通过面向资源的体系结构，服务（命名空间）发布我可以调用方法（方法）的资源（对象）。通过面向服务的体系结构，服务（命名空间）发布我可以调用的操作（函数）。
通过面向资源的架构，我可以根据HATEOAS原则编写自生成客户端。我只需要发回包含链接资源的URL的数据。是否可以通过面向服务的体系结构使用类似的方法？如果没有那么它是否依赖于程序编程的类比，或者是其他原因？
答案 0 :(得分：5)
可以很容易地认为REST架构是一种SOA，它只是对它有更多限制。
HATEOAS方面必须在较低级别的SOA系统之上进行操作，为有效负载添加约束。不要忘记你没有注意HTTP来做HATEOAS。 REST没有绑定到HTTP，HTTP只是一个带有REST灵感的协议。
例如，在您的SOA有效负载中，您可以拥有自己的内部链接引用。这些网址会有网址，但网址不一定是http://example.com。它们可以是yourapp://your?custom!url:format。第一次冒号后的所有内容都由方案解释（在这种情况下为yourapp与http）。
这些不一定是直接参考。在HTTP中，它们不是直接引用，例如，它们依赖于DNS查找主机名。您可以使用自己的发现协议（LDAP，UDDI，/ etc / hosts等）实现自己的查找机制。
SOAP标头与HTTP标头没有区别。不同之处在于如何解释这些头文件的语义。例如，如果您具有解释它的基础结构，则始终可以将缓存标头添加到SOAP有效内容中。
因此，将HATEOAS添加到通用SOA当然是可能的。随着您从REST架构中添加越来越多的约束，您将慢慢变得更像REST。您可能完全不同于Web和HTTP，因为您使用不同的有效负载，不同的传输和不同的协议，但这是一个细节。 REST！= HTTP。
介意，我不是说这很容易。你必须做一些提升，工具包会打你。但这是可能的。