RESTful 分页查询 API 如何设计?

[RiceMarch]

最近在尝试写一点小东西，在设计接口时产生了一些疑惑(・∀・(・∀・(・∀・*)

在 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 的理解还有很大的偏差...

[Jooooooooo]

就是一长串的

[huijiewei]

?xxxxxxx 即可

[liuxey]

如果要完全按照 Restful 风格，那么可以参考《 RESTful Web Services Cookbook 中文版》中的“如何设计集合表述”，但实际感觉并不是很方便，建议 /api/somethings/?p=2&s=10 一把梭

[qiayue]

url rewrite 可以把 p=2&s=10 变成 /p/2/s/10

[superrichman]

restful != path variable

[YUyu101]

/p/2/s/10 哪里好看了，分页不就是查询条件吗，放在参数里很正常啊，换个说法不就是 limit skip 吗，get 查询条件嫌长还可以放 body 里，反正 es 是这么做的。

[dzdh]

首先查询条件放到 request body 并没有任何不合适

其次，直接 querystring 非常合适。or ?filter=jsonstring&limit=xx&offset=xx

[chinvo]

rest 不是不用 query string.

我习惯 ?before=xxx&size=xxx

[Kobayashi]

你不对劲

[rationa1cuzz]

个人喜欢明显第一个好，清晰、明了一看就知道是啥意思，恕我直言，第二种我看的好蠢

[aleung]

根据定义，query string 就是放查询条件的，前面部分标识的是资源。如果你把不属于资源标识的过滤条件放进去，反而不符合 REST 了。

[unco020511]

path variable 应该是 id 之类的资源标示,所以你的参数应该按照是否属于资源标示这样的标准来区分放在 path variable 还是 querystring,另外按照 frc 的建议,get 携带 requestbody 应该是不太合理的(但不是禁止).以上个人见解不一定对

[jiaweilee]

第二种怎么看都很蠢啊

[jotpot]

感觉不要太纠结了，3 楼正解

[dddd1919]

首先要理解 restful 的核心：resource，不是所有东西都是 resource，就像分页和查询条件
另外，也没说不让加参数啊

[xkeyideal]

2C 页面用第二种呢可能会优雅有点，但你这种参数太多了说真的也难看。
内部系统呢，那么第一种绝对是简单高效的，优点如下：
1. 不会出现后续需求迭代时出现路由冲突
2. 对前端来说传参简单明了，对后端维护起来也简单，可读性强，
3. 约束性强，key value 明确，不会出现传参出错，debug 半天后发现传参错位的 zz 行为