oop - 是否可以通过 SOA 应用 HATEOAS 原则？

Question

这个问题是理论上的。我发现面向资源架构和面向服务架构之间的区别类似于面向对象编程和过程编程之间的区别。通过面向资源的架构，服务(命名空间)发布资源(对象)，我可以在其上调用方法(方法)。通过面向服务的架构，服务(命名空间)发布我可以调用的操作(函数)。

通过面向资源的架构，我可以编写一个自生成的客户端，因为 HATEOAS 原则。我只需要发回包含链接资源 url 的数据。是否可以通过面向服务的体系结构使用类似的方法？如果不是，那么它取决于与过程编程的类比，还是其他原因？

Answer 1

可以很容易地认为 REST 架构是 SOA，只是对其有更多限制。

HATEOAS 方面必须在较低级别的 SOA 系统之上加以利用，从而为有效负载添加约束。不要忘记您不注意 HTTP 来执行 HATEOAS。 REST 未绑定(bind)到 HTTP，HTTP 只是一个受 REST 启发的协议(protocol)。

例如，在您的 SOA 负载中，您可以拥有自己的内部链接引用。这些将具有 URL，但 URL 不必看起来像 http://example.com .它们可以是 yourapp://your?custom!url:format。第一个冒号之后的所有内容都由方案解释(yourapp 在这种情况下与 http)。

这些不一定是直接引用。在 HTTP 中，它们不是直接引用，例如，它们依赖于 DNS 查找主机名。您可以使用自己的发现协议(protocol)(LDAP、UDDI、/etc/hosts 等)实现自己的查找机制。

SOAP header 与 HTTP header 没有区别。不同之处在于如何解释这些 header 的语义。例如，如果您有解释缓存 header 的基础架构，则始终可以将缓存 header 添加到 SOAP 负载。

因此，将 HATEOAS 添加到通用 SOA 中当然是可能的。随着您从 REST 架构中添加越来越多的约束，您会慢慢变得更像 REST。您可能与 Web 和 HTTP 完全不同，因为您使用不同的有效负载、不同的传输方式和不同的协议(protocol)，但这只是细节。 REST != HTTP。

注意，我并不是说这很容易。你必须做一些提升，工具包会打败你。但这是可能的。