规哪门子范，就一个风格。执笔无定法，还是面向房贷编程吧。能带来工资的 Webservice 还在 PRD 跑的呼呼的呢。。。

现在微服务之后其实很多时候操作比较复杂，很难讲面对哪一个资源模型做操作，RESTFul 那一套很难描述

Rest 是强依赖 CRUD 模式的。不是 CRUD 场景就不需要 RestFul

这个规范就是个鸡肋，影响自己的总体规划，规范提供的那几个场景基本用不到

遵守，挺好的。

有利有弊，听老板的。

超出资源和四个动词的概念就必须得额外约定。

RESTFul 只是一个 CURD 业务场景下的推荐标准，尝试标准化，只是一个功能子集。

很容易就突破 Restful，比如 search 这个动作，就很容易打破 Restful 他不属于 资源，又会超出四个标准动作。

把它设计成 resource，then restful

是的 一个首页 请求 7 8 个接口 后来给首页单独定制一个接口 restful 其实也不是万能的

已经没用了，Web 端可以这么玩。 现在全是 App 和小程序端，哪里来的 restful。 你可能会说，restful 方便，只要统一做好了，App 和小程序同时调用，方便的很。 这都是理想情况。

真实情况是，restful 一上，App 和小程序一个页面，调用 4,5 个接口。然后一不留神，修改了一些东西，一起爆炸。

可以不用，但不能不懂，graphql 也是一样，可以定规则但前提是有一定的见识

把什么当成资源最重要，事物的状态从创建删除套接字链接、到改单个数据字段、整个模型，至少得有有两个状态请求路径（一样的时候用 METHOD 区分）吧？这才是 REST 而不是一味的 index、edit。REST 只是把资源绑定到 HTTP 路由和方法上，不是命名的这 7 个默认值。 所以这被楼上叫做"必须的规范"我不敢苟同，是不是理解错了？ 当然你要全部用 post 额外参数来做也可以我觉得没必要。