我写了接口文档,尽量按照 RESTful 风格写的,然后前端+部分后台同事说不能用 put 和 delete,还有 path 里不能带参数; 我问为啥,他说这样不规范 我该如何说服同事?
获取对应学期下评语:[get] /back/remark/{termId} 删除数据:[delete] /back/record/{recordId}
搜索 site:v2ex.com restful 了解更多
nginx 日志分析火葬场。。。。
POST /api
{“method”: “get”, “type”: “remark”, “termId”: “{termId}”}
POST /api
{“method”: “delete”, “type”: “record”, “id”: “{recordId}”}
选择规范的标准就是简单，说实话我也不喜欢 RESTful 那套，直接 post/get 就够用了 ，弄一堆 method 那么复杂。
另外 path 里带参数，这种 url 确实便于理解，我以前也挺喜欢这种风格的。但对后端来说，有的框架不能匹配这种 url ；对于前端来说，不利于代码结构化。所以现在也放弃了 path 里带参数
其中
/api 是 path
?a=1&b=2 是 query string
path 可以理解为资源定位,那 id 放在 path 里获取资源不应该更合理吗;
还有前端框架不支持也有点牵强,我原先做移动端+web,都是支持的,且新框架一般都支持的很好,比如 android 的 retrofit
1.监控问题：因为监控 URL 请求的时候，需要进行 URL 聚合统计操作，如果用 RESTful 风格 非常难以提取 URL 的模型进行聚合（因为有人用 python，有人用 java，还有不同的应用框架，非常难以在 client 端进行 url 模式提取。而在 server 端模式提取要求的性能又很高。还不如直接用 get 和 post ）。
2.配套的日志采集系统：RESTful 风格 在独立上下文的日志引擎里，很难用 URL 进行模式提取。
3.配套的其他系统的问题： 统一 API 网关接入（如果是自研的，需要完整支持 restful 风格）。自动化测试系统（如果自研，也要兼容）。代码审计和代码覆盖平台 等等。
如果你用了 RESTful 风格，那么需要整个 开发运维链路上的每个环节，都要支持完整的操作。但是实际上，很多系统只是支持简单的 GET 和 POST 协议。
你不得不推动 每个团队来支持你的需求，这个等待 是很麻烦的。
这种类型的 url，有的框架是不支持的
当然有几点要注意：
一，RESTful 是一种编码风格而不是工具，只存在用不用，不存在尽量用，若你不能让所有接口都遵循 RESTful，那就不要用。
二，RESTful 与 HTTP 相互适应，但与 HTML 并不相互适应，APP、好的前端框架能够很容易的适配 RESTful 接口，但一般的前端框架以及不用框架的 Web 开发，是只认 get、post 不认其他请求的（严格的说，底层技术是支持其他请求的，但是框架设计思想上不支持）。
三，如果接口是 RESTful，那么底层既是不是领域驱动设计，也要对此有所了解，否则你在 URI 命名上绝对会遇到矛盾。
那应该能列举这么干的坏处和按照你这么干带来的好处
一句规范打发大家毫无说服力
(带来收益的事情才去做
如果支持 RESTful 风格 很容易支持的话，早就全支持了。 业务方不允许你的采集程序占用额外的内存和 CPU，自己部署的中间件平台为了额外的模式提取需要付出性能代价 而加机器。这些个都是成本制约。
如果 RESTful 风格 在没有上下文的前提下，很容易像 POST 一样提取模式，无其他明显成本消耗，就不会这么不建议了。
api?k1=v1&k2=v2 (没有上下文，各个系统能快速解析)
与
api/k1/v1/k2/v2 或者 /mock/a/k1/v2 （没有上下文，面对海量的各种地址的 URL 请求，需要付出额外的资源进行解析）
至于说框架 /标准库支持, 那是实现方的具体实现, 没有任何实际意义.
等你部署上线的时候, 你的服务器支持, 但是负载均衡不支持, 客户端类库不支持, 那么你这个还叫 http 服务器??
我个人在实践里面，和前面别人提到的一样，API 只用 POST，URL 里不加参数，统一 data 传参数
就像我厂 golang 的 const 变量都是 大写+下划线，不符合 go 官方风格
http 本来就是传输协议啊，Hyper Text Transfer Protocol 直译过来就是超文本传输协议，写得明明白白。web 是 web，http 是 http，两者并不相等。