未分類
8 4 月 2021

RESTful 分页查询 API 如何设计?

RESTful 分页查询 API 如何设计?

資深大佬 : RiceMarch 4

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

在 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)

  • 資深大佬 : 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 行为