这是一个创建于 1699 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在尝试写一点小东西，在设计接口时产生了一些疑惑(··(··(··*)
在 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 PRO 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