面向资源架构与大型 Web 服务的对比解析
1. SOAP 传输与面向资源的替代方案
在企业防火墙后,JMS 传输有一定应用,但绝大多数 SOAP 流量是通过 HTTP 传输的。SOAP 几乎总是通过 HTTP 发送,然而 SOAP 工具包很少使用 HTTP 状态码,并且倾向于将所有操作都强制转换为 POST 方法。这在技术上并不违反 REST 架构风格,但这是一种退化的 RESTful 架构,无法获得 REST 应有的好处。大多数 SOAP 服务支持对不同数据的多种操作,所有这些操作都通过单个 URI 上的 POST 方法进行中介,这不是面向资源的,而是 RPC 风格。
为了改进这种情况,可以进行以下重要更改:
- 将服务拆分为资源 :为服务中的每个“事物”分配一个单独的 URI。几乎所有现有的 SOAP 工具包都提供了访问此信息的途径,将对象引用放在前面。虽然这种用法一开始可能感觉不那么自然,但如果仔细思考,这正是如果 SOAP 真的是简单对象访问协议时所期望的做法。这就像在面向函数的语言(如 C)和面向对象的语言(如 C++)中进行面向对象编程的区别:
- 在 C 语言中: my_function(object, argument);
- 在 C++ 语言中: object->my_method(argument);
- 当将作用域信息移到括号(或在这种情况下,SOAP 信封)之外时,很快就会发现大量具有共同功能的资源,进而可以重构逻辑以利用这些共性。
- 利用多态性 :尝试让不同类型的对象对具有相同名称
超级会员免费看
订阅专栏 解锁全文
10万+

被折叠的 条评论
为什么被折叠?



