问题1：RESTFul 是不是必须的，是不是设计 API 的最优解？
RESTFul 只是一个风格，作者都承认这只是一种风格，风格就是“可选择的”，“可插拔替换的”，在强度上远远弱于“协议”。
凡是上升到协议的东西必须要多方达成一致共识，共同维护且必须遵守，有一定的强制性。
比如 TCP/IP 协议栈中的各种协议，你不这样做就一定不能和其他程序通信。
RESTFul 在表达某些业务场景的时候并没有强大的普适性，必须要额外的进行一层加工：将一个行为（action）进行转换，转换为对资源（resources）的某种动作（action）。
又在业务逻辑上额外的引入了一层不必要的复杂度：资源
很明显，世界上不是所有的业务都适合用 “资源” 来表示，比如用户登录，用户注册，如果你一定要生搬硬套脱离语义的搞，那么就是：
用户登录：`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，而且 GET 可以被缓存。
如果是系统内部的通讯使用 HTTP 协议，用作 RPC API，全部使用 POST 反而能让事情变得更简单，这种情况下不需要使用 GET 的 “URL 记录元信息” 的能力。