3

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

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

4

1 回答 1

5

可以很容易地认为 REST 架构是一种 SOA,它只是有更多的限制。

必须在较低级别的 SOA 系统之上利用 HATEOAS 方面,从而为有效负载增加约束。不要忘记您不注意 HTTP 来执行 HATEOAS。REST 不受 HTTP 约束,HTTP 只是一个包含 REST 灵感的协议。

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

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

SOAP 标头与 HTTP 标头没有区别。不同的是如何解释这些标头的语义。例如,如果您有基础设施来解释它,您总是可以将缓存头添加到 SOAP 有效负载。

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

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

于 2013-10-22T21:46:04.177 回答