各位后端大佬，请问这样的后端接口命名正常嘛？

有可能使用工具批量生成的，但只要传参出参合理就行啦

有点 REST API 那味道，但是没有晚安按照 REST API 来

晚安 = 完全

@Nicoco #2 不应该吧 delete update 等“动词”放到 url 上面来，应该用请求方法区分

我们的后端接口只有 post，最后一个字段和你的差不多

我不要下划线，要么驼峰，要么横线链接。

REST 规范 URL 里面不应该包含动作，动作应该由 HTTP 方法指定
更新这种操作应该用 PUT，POST 用于建立一条新的数据
后端能按时给接口就万岁了，查询接口都有用 POST 的
刚出校门还有点洁癖，后来想想，当社畜何必拘小节

@vision1900 复杂查询不用 post 用什么呀？ 仅仅 get 满足不了需求呀

@PopRain 复杂能有多复杂，100 个参数？ get 又不是做不到，query string 我目前还没遇见过什么限制

没啥问题，命名统一，看 url 就能看出是干啥
复杂查询虽然可以 GET，但是不如 POST 省心省力
曾经多少有点洁癖，最后还是选择全部 POST+路径里带动词
REST 洁癖还是留给那些全部大佬又不需要赶工的团队吧

一般 get 代表获取，post 代表上传 /修改 /删除 然后加个标志 因为很多 cdn 只转发 get/post

@vision1900 使用 get，参数多的话，会有丢失的情况。请问你是怎么解决的

@PopRain 复杂查询时可以将 query 丢到 body 里面呀

还可以了。 很难严格的 restful 的，会有一些乱七八糟的问题。 我们就是从 restful 风格后面干脆全部 post，然后 url 上加动词了。

还行啊，挺规范的，现实中根本不可能完全按 RESTful 来，只是个参考而已

httpe method 已经表示动作了呀

挺好 简约简单

我觉得挺好的，非常统一

你发出来 就是有疑问 你不讲讲你的疑问？？

@PopRain 前段时间爬抖音，抖音的 get 里都是一百多个参数

虽然不 rest，但挺工整的，又不是不能用

工整，方便封装，request[delete|select|insert|update] = (tableName, params) => {...};

多了 我会看眼花

想问一下，要是 /user_role/select 这种有多个 select 怎么写？

可以怎么舒服怎么来，如果一定要按 rs 风格，这种肯定不标准咯

@daxiaBoy #12 最短的 IE 限制 url 长度也能有 2048 字节，你的是什么请求要超过这个长度。。。

我是前端，完全可以接受。只要一个项目坐下来接口命名都是有规律的，都能接受

@daxiaBoy #12 你该不会是没有 urlencode 导致 url 被截断了吧

这种挺好的，delete 也 post 就更好了，闭着眼都能写，有操作数据库的感觉。

非常常见的做法，也许理论上不完美，但肯定是 work 的，而且应该会完美 work 的。没有理论洁癖的就乖乖用着，你说它能产生什么不好的事情么？是影响了产品质量了还是影响用户体验了还是影响开发效率了还是影响系统性能了……这么有规律的接口甚至连未来升级 GraphQL 都不会影响

@ochatokori URL 参数多确实是很容易被截断的，有一段时期的 nginx 默认配置就是 2048 截断，然后现在网络上有大量的中间代理服务器还是这个配置，你永远不知道用户的请求到你的服务器会经过哪些代理，这些代理会不会干出啥傻事来
至于为什么 2048 不够……多选 1000 行批量操作

不是纯 POST，这最后一截就不需要了吧……

restful man 已经饥渴难耐

没啥毛病。。。

这么清晰你还要啥

哦写成这样那为什么不用 graphql 呢

RESTful API 的路径不是不能有动词啊，重要的是资源的抽象。当 HTTP 方法不能完全表达动作内容时，加在路径上也没啥问题，比如 `POST /resources/<id>/<action>`
当然楼主给的接口确实也不是 RESTful API

之前也特别纠结复杂查询包括搜索时的参数问题，因为 REST 的话应该是 GET，后来网上看到有人的做法是 POST /resource/search， 感觉这点也是能接受的，所以其实能在已有的标准上形成一个自己的标准就好，目的是统一好理解，除此之外任何做法都是正确的

restiful 本来就是 Style， 不是 Spec

get post 就完事了

你见过拼音首字母缩写+简单英文的 URL 么

挺清晰的，一看就懂没毛病..但是还是直接一个 resource 简洁舒服

话说，我这边是后端 controller 层整合数据的，前端一般只管展示，第一次看到这种接口确实蒙了一下

其实有规律就好了，这个能看出规律，知道是干啥的就行了。。。

我觉得挺好的

不都是这样吗？



看看我们后端的，貌似有不正常的地方？

脱裤子放屁，不好意思，我就是这么粗俗

不正确，不正常，但是常见。

名称是抄的 restful 规范，但是 restful 是不含 delete,insert,get,update 这类词的，http 头的 action 指定的。

个人猜测，这是批量生成的接口。

正常，风格统一，容易分类，一眼就能看出是做什么的，因为我都是用 post 跟 get，所以接口里都会有一个“操作”的标识

又不是不能用

只要统一就行
这样显示点儿也没啥不好的。。

丑...

这规范 那规范 没啥用

这样命名挺工整统一的，不过只能应对简单场景 api 。

restful api 同样只能应对普通 crud 。各种关系组合查询都难以应对。

@vision1900 GET 请求也是有限制的，第一个是长度限制，第二个不可以传结构化数据比如 application/json

这接口挺好的，虽然不是 restfull 规范，但也很规范了，而且一看就知道干啥的

我们让后台全部给 POST 接口 这样方便

你这还不如都用 post 呢，偏偏 delete 用 delete 就很蛋疼

挺正常的接口。从 URL 可以知道干啥了。

正常吧

如果后端的接口没有指定 get 、post...的话用 swagger 生成就是这种的

#60 看错了。。

这中间的是表名吧

restful 只是一种风格，又不是前后端接口交互的规范，只要自己人约定好了，没有问题就可以了。哪那么多高潮的。

如果按照 restful 风格的话,一般是不出现动词的,path 指向需要操作的资源,通过 mthod 来指定动作.不过这也只是一种风格,倒也不必强行去套

@newmlp 这话适用于大部分类似场景,哈哈

不能在正常了，少见多怪

把 insert/update/select/delete 去掉，同事 ${resource_id} 到路径中 应该会规范一些。

即使 get 请求也可以传 body 的，没看 elastic search 就是这么干的吗

@vision1900 #7 又是那些教条，实际上后台的接口 含义根本不可能是那几个动作能说清楚的

@unco020511 本来就是啊，程序是用来用的，又不是打官司，哪有那么多规矩

@lewis89 大佬说的对

少挑毛病，把事情做好，除非有什么大问题
你想按照规范，就来主导这件事情，不是别人做好之后怀疑规不规范

@wc951 这个不敢苟同,如果按照 http 协议,get 是没有 body 的,get 是用来获取数据的,为什么要有 body

@wc951 #68 这个就不是接口设计风格的问题了，连 HTTP 协议本身都不遵守了，那还是换个协议吧

难道不是你们用的开心就可以吗？这种事情没有对错，只有倾向。但是确实不是严格的 restful 风格，然而遵循严格的 restful 风格付出的成本相对比较高，一般业务还是难以坚持下去的