Rest vs Soap 比较
一、前言
昨天为止,政府的一个公共部门的项目顺利结束,就系统间消息传输这个点,知识点总结一下。本文主要参考octoperf的文章,链接见文末参考资料。
系统中用到的是SOAP协议进行传输数据,有人会立马会问为什么不用Rest,它更快,更简单。可能会说一大堆东西来反驳这个继续选型。技术,没有好坏,在限定的条件下,合适的就是对的,满足需求的就是好的。下面,进入正文。
二、Rest vs Soap
Rest 是一种构造风格,而Soap是一种传输协议。它们不是同样的东西,因此不能直接进行比较,接下来用一个表格,就某些点来进行比较。
sdfdsf | SOAP | Rest |
当API变化时 | 客户端代码必须用新的WSDL进行在编译 | 后台可兼容 |
同步/异步 | 异步消息 | 同步 |
带宽的使用 | 多 | 少 |
可缓存否 | 不可以 | 可以 |
数据格式 | 只有XML | XML,JSON,纯文本等 |
错误处理 | 内置错误处理机制 | 没有 |
暴露业务逻辑方式 | 服务接口 | URIs |
失败处理 | 内置再尝试机制 | 期待客户端进行再尝试 |
可靠性 | 可靠 | 不可靠。HTTP delete 即使失败,也会返回OK |
安全性 | 支持SSL和WS-Security | 依赖服务设计者提供的文档 |
需要的工具 | 需要中间件的支持 | 只需要支持HTTP即可 |
哪些领域使用 | 金融,支付网关,通信 | 社交媒体,Web,手机 |
2.1 SOAP
SOAP是被Web Services使用的标准的消息协议,主要目标是用于内部的Application的信息传递(SOAP = XML + 通信协议(如HTTP、FTP等))。WSDL(Web Services Description Language)就是描述Web Services的资料。描述了Services的接口,利用相关的工具,可以通过WSDL生成任何语言的、调用services的代码。大多数API测试工具,支持SOAP可以自动测试代码。
2.2 REST
Representational State Transfe
它通过网络暴露出公共API,来对数据进行CRUD操作。
发送请求的例子:
GET /articles?include=author HTTP/1
Json返回响应:
HTTP/1.1 200 OK Content-Type: application/vnd.api+json { "data": [{ "type": "articles", "id": "1", "attributes": { "title": "JSON API paints my bikeshed!", "body": "The shortest article. Ever.", }, "relationships": { "author": { "data": {"id": "42", "type": "people"} } } }], "included": [ { "type": "people", "id": "42", "attributes": { "name": "John", "age": 80, "gender": "male" } } ] }
REST多数情况下依赖于软件架构中无状态网络协议,如HTTP协议。
2.3 比较
二者都有各自的优势,没必要比较哪个好坏,在特定的环境下,合适的才是最好的。鞋子舒不舒服只有脚知道。
2.3.1 Rest优势
· HTTP 通信
· REST易于扩展
· 大量开发者的社区
· 轻便
· 对JavaScript友好
· 可使用XML,Json或其他格式的数据
2.3.2 SOAP优势
·适用于大型企业项目:因为它有许多特性,如XML加密,失败自动重试等。
· 安全性高
·通过标准的WSDL文档定义Services
·适用于有状态的传输交流
·支持多种传输协议如HTTP,FTP,SMTP,纯sockets等。
2.4 使用场景
场景 | SOAP | REST | 理由 |
公共层面接口 | Good | 简单就是最大的理由 | |
高吞吐量的接口 | Good | 性能好,占用带宽少 | |
支付系统 | Good | 安全性好 | |
手机应用 | Good | 目前,使用Json的Rest已成为标准 |
三、结束语
最合适的才是最好的。不需要做无谓的争论。
参考资料:
https://octoperf.com/blog/2018/03/26/soap-vs-rest/