RESTful 分页查询 API 如何设计?

RiceMarch 1月前 27

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

在 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 22天前
    引用 2
    就是一长串的
  • huijiewei 22天前
    引用 3
    ?xxxxxxx 即可
  • liuxey 22天前
    引用 4
    如果要完全按照 Restful 风格,那么可以参考《 RESTful Web Services Cookbook 中文版》中的“如何设计集合表述”,但实际感觉并不是很方便,建议 /api/somethings/?p=2&s=10 一把梭
  • qiayue 22天前
    引用 5
    url rewrite 可以把 p=2&s=10 变成 /p/2/s/10
  • superrichman 22天前
    引用 6
    restful != path variable
  • YUyu101 22天前
    引用 7
    /p/2/s/10 哪里好看了,分页不就是查询条件吗,放在参数里很正常啊,换个说法不就是 limit skip 吗,get 查询条件嫌长还可以放 body 里,反正 es 是这么做的。
  • dzdh 22天前
    引用 8
    首先查询条件放到 request body 并没有任何不合适

    其次,直接 querystring 非常合适。or ?filter=jsonstring&limit=xx&offset=xx
  • chinvo 22天前
    引用 9
    rest 不是不用 query string.

    我习惯 ?before=xxx&size=xxx
  • Kobayashi 22天前
    引用 10
    你不对劲
  • rationa1cuzz 22天前
    引用 11
    个人喜欢明显第一个好,清晰、明了一看就知道是啥意思,恕我直言,第二种我看的好蠢
  • aleung 22天前
    引用 12
    根据定义,query string 就是放查询条件的,前面部分标识的是资源。如果你把不属于资源标识的过滤条件放进去,反而不符合 REST 了。
  • unco020511 22天前
    引用 13
    path variable 应该是 id 之类的资源标示,所以你的参数应该按照是否属于资源标示这样的标准来区分放在 path variable 还是 querystring,另外按照 frc 的建议,get 携带 requestbody 应该是不太合理的(但不是禁止).以上个人见解不一定对
  • jiaweilee 22天前
    引用 14
    第二种怎么看都很蠢啊
  • jotpot 22天前
    引用 15
    感觉不要太纠结了,3 楼正解
  • dddd1919 22天前
    引用 16
    首先要理解 restful 的核心:resource,不是所有东西都是 resource,就像分页和查询条件
    另外,也没说不让加参数啊
  • xkeyideal 22天前
    引用 17
    2C 页面用第二种呢可能会优雅有点,但你这种参数太多了说真的也难看。
    内部系统呢,那么第一种绝对是简单高效的,优点如下:
    1. 不会出现后续需求迭代时出现路由冲突
    2. 对前端来说传参简单明了,对后端维护起来也简单,可读性强,
    3. 约束性强,key value 明确,不会出现传参出错,debug 半天后发现传参错位的 zz 行为
  • 游客
    18
返回