为什么很多后端写接口都不按照 restful 规范？

知乎上有一个问题:https://www.zhihu.com/question/438825740

看看网友的说法1

在接口设计的时候，了解到了RESTful这种接口风格。
一开始我觉得挺好的，把任何接口都简化为对资源的增删改查，感觉网站开发变得清晰了许多。
但慢慢地，随着网站功能的复杂，RESTful逐渐让我变得束手束脚，对接口的设计要纠结很长时间，仅仅是为了那“漂亮”的风格。
而且RESTful的规定显得有些生硬，比如“上传”用“增”，“下载”用“查”，总感觉很别扭。
最终我决定，还是不使用RESTful了，语义化的接口命名更加能够提高开发效率。

看看网友的说法2

说下个人看法，之前按restful风格的接口写过几个版本的项目，实践证明有些地方restful风格接口不理想，下面列举几个地方，实际应该更多1.不是所有的接口都能很方便的抽象为资源，强制抽象得不偿失，不如按业务去定义2.参数分散到路径、query、body三个地方，设计复杂，用户用起来不方便，不喜欢，不买账，不如全放body3.内容返回整个资源造成带宽浪费，高并发尤其明显，不如仅返回需要的字段4.请求方式根据动作设为post get delete patch put等，动词可选择性太少，不够灵活，有些旧项目也不支持patch等，对接有困难，不如把动作直接放url里5.状态码和实际业务差距大，例：密码错误，密码过期，账号不存在，验证码错误，账号已冻结，这些不可能全都一一对应，实际情况大家在创造状态码，或者在body里再加一个字段进行细分最终要用还是得改造很多地方的
我曾经尝试完全使用restful规范写api,太痛苦了,语义完全无法表达.最后直接使用java中的方法名称+post,舒心了.

看看网友的说法3

剑招是死的，人是活的。因为 RESTFul 语意比较不足, 业务一复杂就无法表达出足够清晰的接口意图RESTful 有很多接口上最佳实践，但生搬硬套就会使得接口比较诡异。这里只说生搬硬套 RESTFul 的带来的缺点，并不是整体否定RESTFul。语义不明确比如，业务具备一定复杂性的时候，语义容易不明确。

我用起来实际也是感觉不够灵活，
还有人只用post，

作为一个提醒， 这里就是待完成事项列表 web service 所提供的方法的定义:

HTTP 方法	URL	动作
GET	http://[hostname]/todo/api/v1.0/tasks	检索任务列表
GET	http://[hostname]/todo/api/v1.0/tasks/[task_id]	检索某个任务
POST	http://[hostname]/todo/api/v1.0/tasks	创建新任务
PUT	http://[hostname]/todo/api/v1.0/tasks/[task_id]	更新任务
DELETE	http://[hostname]/todo/api/v1.0/tasks/[task_id]	删除任务

上面这篇文章中有个例子
GET /zoos：列出所有动物园
POST /zoos：新建一个动物园
GET /zoos/ID：获取某个指定动物园的信息
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
DELETE /zoos/ID：删除某个动物园
GET /zoos/ID/animals：列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

对比下面这一个
list_zone：列出所有动物园
create_zone：新建一个动物园
get_zone_by_id：获取某个指定动物园的信息
update_zone：更新某个指定动物园的信息（提供该动物园的全部信息）
update_zone：更新某个指定动物园的信息（提供该动物园的部分信息）
delete_zone：删除某个动物园
get_animals_of_zone：列出某个指定动物园的所有动物
delete_animal：删除某个指定动物园的指定动物

那个更清晰, 更精确, 更易于理解不是显而易见?我唯一能想到的restful的优势就是, restful可以带来的难以维护的代码让人不容易失业
restful is a piece of shit!