![[Pasted image 20231114211549.png|600]]
问题1：RESTFul 是不是必须的，是不是设计 API 的最优解？
RESTFul 只是一个风格，作者都承认这只是一种风格，风格就是“可选择的”，“可插拔替换的”，在强度上远远弱于“协议”。
凡是上升到协议的东西必须要多方达成一致共识，共同维护且必须遵守，有一定的强制性。
比如 TCP/IP 协议栈中的各种协议，你不这样做就一定不能和其他程序通信。
RESTFul 在表达某些业务场景的时候并没有强大的普适性，必须要额外的进行一层思维上的加工：
将一个行为（behavior）进行转换，转换为对资源（resource）的某种动作（action）。
behavior = f(resource + action)
可是这样一搞，又在业务逻辑上额外的引入了一层不必要的复杂度：资源
很明显，世界上不是所有的业务都适合用 “资源” 来表示，比如用户登录，用户注册，如果你一定要生搬硬套脱离日常语义的搞，那么就是：
| 接口功能 | 非 RESTFul 表示 | RESTFul 表示 |
|---|---|---|
| 用户登录 | POST /login |
POST /session/create |
| 用户注册 | POST /register |
POST /user |
这样做很违反直觉，就和 Yoda 表示法 一样让人不舒服。
而且 RESTFul 还有一个严重的问题，很多业务逻辑并不是那几个简单的 HTTP 方法就能完全描述的，比如说 骑自行车，用什么 HTTP 方法去描述这个行为呢？
我们进行一个思维转换，得到了自行车作为资源，那么就是 POST /bike，可这不变成了创建自行车了么？
还是把驾驶员作为资源？使用 POST /bike/driver 创建一个驾驶员？
所以让 RESTFul 去解释世界上所有东西，甚至认为是圣经一样的规则不容破坏是一件很不合适的做法。
问题1：GET 和 POST 有什么区别，我能只使用 POST 吗？
这个问题要看在什么情况下使用这两个方法。
如果是对外的一些服务，比如一个 web 服务，用户使用浏览器访问你的网站，需要 URL 内的查询参数来辅助一些操作，比如保存书签，或者转发 URL，亦或者我们需要跟踪用户的 URL 用来做历史记录，方便进行前进后退。这种情况就应该使用 GET，而且 GET 可以被缓存。
如果是系统内部的通讯用作 RPC API，全部使用 POST 反而能让事情变得更简单，这种情况下不需要使用 GET 的 URL 记录元信息 的能力。