之前技术群里有人转发了一个建议后端所有接口都使用POST来与前端交互. 当时仔细看了下,大概的思路是觉得用POST更统一,也没什么坏处云云..
现在比较流行的使用HTTP来做前后端交互的应该是RESTful风格. REST把HTTP里的动词作为对资源的一种操作,例如GET对应获取,POST对应创建,PUT和PATCH对应更新等.这里不详细说规范的细节.只说一些我认为的原则上的问题和一些设计上的遗漏.
设计方面的思考
一个好的设计,应该是通用的,被大家所接受的.
形成一个好的规范设计,可以降低相关人员的理解成本.
比如说都用RESTful风格,那么大家看你的接口就知道你想表达的意思.开发人员在看到GET的接口,就知道这是一个获取资源的接口,我可以认为他是幂等的.而网关等中间层就可以基于此来进行缓存,例如浏览器缓存,CDN缓存等.这样就无需再度沟通就达成了一种共识.
而规范设计带来的共识则是在减少整个社会的无用功上发挥了非常大的作用. 我只需要按照规范来,那么就可以适配其他所有也按照规范来设计的产品. 世界上的组织例如国际标准化组织 (International Organization for Standardization), 就在规范设计方面发挥了很大的作用.
如果规范过于小众,在适用的范围就会变小,而这就不利于整个群体的利益.只用POST的人没有办法享受到那些基于REST的一些例如缓存服务,而在面对RESTful风格的设计时,又不得不再学习理解一遍.
技术方面的思考
从技术上来说,HTTP本身只是作为一种通信协议,跟业务什么都没有太大关系. 理论上来说的确都使用POST和使用RESTful风格的设计都可以满足完成通信达成业务需要.但是我认为在都能完成需求的前提下,选择成本最低的方案肯定是没问题的.
而相较于RESTful风格,只使用POST的依然需要去对业务的语义进行描述,只不过可能是放在了接口中.而且一旦规范定义的不好,例如同一个获取,有人用了xx/get表达,有人用了xx/query来表达,又增加了理解成本.
总的来说,技术上还是围绕着如何在满足需求的情况下,降低成本,而降低成本的方向上,设计模式,开发规范, 先进技术等都是一些方向.我并不觉得都使用POST有比REST API有达到一些优势.相反,在整个大局上,还会带来一些技术负担.
思想方面的思考
不要把复杂的问题简单化,因为最终你还是要解决复杂问题的方方面面.而且更重要的是简单不是针对小部分人的.
不要把简单的问题复杂化.
尽可能的提升自己的理解高度,才能分清复杂和简单.
原则上设计要尽量贴合现代理论, 但也别太拘泥于特定的实现, 也要结合自己的实际情况去做.
就像一个登录接口, 非要贴着RESTful风格, 想着是对session的操作, 所以是对session进行get和post, 接口也是GET /session, POST /session, DELETE/session.但是使用POST /login, 其实语义上也是非常清晰的. 毕竟不是所有的接口都是对单一资源的增删改查操作.
