一、前言
昨天为止，政府的一个公共部门的项目顺利结束，就系统间消息传输这个点，知识点总结一下。本文主要参考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/