这是一个创建于 1360 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在尝试写一点小东西，在设计接口时产生了一些疑惑(・∀・(・∀・(・∀・*)
在 RESTful API 中资源的获取是 GET,
假设一个场景 需要进行分页查询，有着复杂的查询条件。
那么我的 uri 就变成了下面这样一长串,后面携带了一长串查询条件
/api/somethings?p=2&s=10&q=sdasdad&type=xx&time=xx&o=desc
但我想象中的 restful 是这样的帅气模样
/api/somethings/p/2/s/10 ....
有想过用 requestbody 把查询条件进行封装，但这明显不合理。
好奇如何设计出“好看”的 restful API 呢？（可能我对 restful 的理解还有很大的偏差...
16 条回复 • 2021-04-09 17:24:54 +08:00
 |
1
Jooooooooo 2021-04-08 23:09:46 +08:00
就是一长串的
|
 |
2
huijiewei 2021-04-08 23:10:25 +08:00
?xxxxxxx 即可
|
 |
3
liuxey 2021-04-08 23:11:18 +08:00  1
如果要完全按照 Restful 风格，那么可以参考《 RESTful Web Services Cookbook 中文版》中的“如何设计集合表述”，但实际感觉并不是很方便，建议 /api/somethings/?p=2&s=10 一把梭
|
 |
4
qiayue 2021-04-08 23:11:28 +08:00
url rewrite 可以把 p=2&s=10 变成 /p/2/s/10
|
 |
5
superrichman 2021-04-08 23:21:58 +08:00 via iPhone 1
restful != path variable
|
 |
6
YUyu101 2021-04-08 23:42:00 +08:00 via Android
/p/2/s/10 哪里好看了，分页不就是查询条件吗，放在参数里很正常啊，换个说法不就是 limit skip 吗，get 查询条件嫌长还可以放 body 里，反正 es 是这么做的。
|
 |
7
dzdh 2021-04-08 23:58:48 +08:00 1
首先查询条件放到 request body 并没有任何不合适
其次，直接 querystring 非常合适。or ?filter=jsonstring&limit=xx&offset=xx |
 |
8
chinvo 2021-04-09 00:05:01 +08:00 via iPhone 1
rest 不是不用 query string.
我习惯 ?before=xxx&size=xxx |
 |
9
Kobayashi 2021-04-09 00:23:25 +08:00 via Android
你不对劲
|
 |
10
rationa1cuzz 2021-04-09 09:31:05 +08:00 1
个人喜欢明显第一个好，清晰、明了一看就知道是啥意思，恕我直言，第二种我看的好蠢
|
 |
11
aleung 2021-04-09 10:07:05 +08:00 via Android
根据定义，query string 就是放查询条件的，前面部分标识的是资源。如果你把不属于资源标识的过滤条件放进去，反而不符合 REST 了。
|
 |
12
unco020511 2021-04-09 10:16:46 +08:00
path variable 应该是 id 之类的资源标示,所以你的参数应该按照是否属于资源标示这样的标准来区分放在 path variable 还是 querystring,另外按照 frc 的建议,get 携带 requestbody 应该是不太合理的(但不是禁止).以上个人见解不一定对
|
 |
13
jiaweilee 2021-04-09 12:15:33 +08:00 via Android
第二种怎么看都很蠢啊
|
 |
14
jotpot 2021-04-09 13:04:00 +08:00
感觉不要太纠结了，3 楼正解
|
 |
15
dddd1919 2021-04-09 13:32:57 +08:00 1
首先要理解 restful 的核心：resource，不是所有东西都是 resource，就像分页和查询条件
另外，也没说不让加参数啊 |
 |
16
xkeyideal 2021-04-09 17:24:54 +08:00
2C 页面用第二种呢可能会优雅有点，但你这种参数太多了说真的也难看。
内部系统呢，那么第一种绝对是简单高效的，优点如下： 1. 不会出现后续需求迭代时出现路由冲突 2. 对前端来说传参简单明了，对后端维护起来也简单，可读性强， 3. 约束性强，key value 明确，不会出现传参出错，debug 半天后发现传参错位的 zz 行为 |
Select Language