问题是理论上的。我发现面向资源的体系结构和面向服务的体系结构的区别类似于面向对象编程和过程编程的区别。通过面向资源的体系结构,服务(命名空间)发布我可以调用方法(方法)的资源(对象)。通过面向服务的体系结构,服务(命名空间)发布我可以调用的操作(函数)。
通过面向资源的体系结构,由于HATEOAS原理,我可以编写一个自生成客户端。我只需要返回包含链接资源的urls的数据。通过面向服务的体系结构可以使用类似的方法吗?如果不是这样的话,它是依赖于与过程编程的类比,还是其他原因呢?
发布于 2013-10-22 21:46:04
可以很容易地认为REST体系结构是SOA,它只是有更多的限制。
必须在较低级别的SOA系统之上利用HATEOAS方面,为有效负载添加约束。不要忘记,您不注意HTTP来执行。REST不绑定到HTTP,HTTP只是一个带有REST灵感的协议。
例如,在SOA有效负载中,您可以有自己的内部链接参考。它们将有URL,但是URL不必看起来像http://example.com。他们可以是yourapp://your?custom!url:format。第一个冒号之后的所有内容都由该方案解释(本例中为yourapp对http)。
这些并不一定是直接的参考。在HTTP中,它们不是直接引用,它们依赖DNS查找主机名,例如。您可以使用自己的发现协议(LDAP、UDDI、/etc/host等)实现自己的查找机制。
SOAP头与HTTP头没有什么不同。不同的是如何解释这些头的语义。例如,如果您有解释SOAP有效负载的基础设施,则始终可以向SOAP有效负载添加缓存头。
因此,当然可以将HATEOAS添加到通用SOA中。当您从REST体系结构中添加越来越多的约束时,您将慢慢地变得更像REST。您可能完全不同于Web和HTTP,因为您使用不同的有效负载、不同的传输和不同的协议,但这是一个细节。REST != HTTP。
我不是说这很容易。你必须做一些提升,工具箱会和你搏斗。但这是可能的。
https://stackoverflow.com/questions/19518647
复制相似问题