因为 http 的协议设计还是有点落后了, 所以才有了 api 接口自定义业务状态码的需求.

[fkdog]

其实不止是状态码, http 协议里的其他有缓存控制、权限认证、资源请求格式等等头放在如今的后端开发里也是很少有再用到, 原因大体基本相同, 就是扩展性太差. 这些东西服务端可以自己做, 而且还能做的更好.

二三十年前那会的 http 用途和今天的 http 用途已经不可同日而语. 以前的协议 http 设计是以资源为中心的超文本传输协议, http 的许多头字段都是围绕着如何获取资源来进行的. 而如今互联网承载了许多行业的业务, http 那些老旧的设定已经远远不能满足现代开发需求, 因此 http 也慢慢退化成了只是用来传输业务数据的载体, 所以 http2.0/http3.0 几乎已经没有在这些方面进行扩展了, 因为把业务相关的东西交给应用服务器本身去处理去更合适.

考虑到这一点自然就不难理解 V2EX 上的那些日常《 http status 和业务状态码》、《设计 api 是否应该严格按照 restful 风格》的 battle 了.所以不要把 restful 之类奉为圭臬, 也不要一天到晚吃饱了没事干 diss body 里包业务码的设计.

隔壁 php 框架早开始用 index.php 做统一入口了, url 分发用参数. 支付宝的服务网关都只有单入口, 具体的访问 endpoint 直接以参数体现. apple 、github 这些站点 url 能看出来是 restful, 但是由于业务规模迭代, 许多页面的接口设计也早就不 restful 了.

不知道这些例子能不能敲碎 restful 教徒的玻璃心.

[wanguorui123]

HTTP 在朝着 HTTP-RPC 的方向走

[xiaopc]

「缓存控制、权限认证、资源请求格式等等头」是给前端用的，后端通信为什么不去用 RPC
PHP 用 index.php 做入口是伪静态年代开始的，Laravel 甚至 ThinkPHP 都没有在用了
不要觉得后端就是一切

[fgwmlhdkkkw]

确实，restful 对用户来说，手打链接的情况下，当然是友好的，但是现在什么业务都要做 app，就算是网页的交互也越来越华丽，restful 对用户来说屁用没有。
但是，如果可以，我还是愿意 restful……