这是一个创建于 1263 天前的主题，其中的信息可能已经有所发展或是发生改变。
是这样，我是前端，但是最近打算学写 api，想试试 RESTful API，看了[阮一峰的这篇文章]( http://www.ruanyifeng.com/blog/2014/05/restful_api.html)，在开始前我就想到了可能会遇到的一些问题：
1. GET 方式参数都拼在 url 上，但是有时候一个接口甚至会携带十几个参数，比如我们现在的后台管理的一些列表就是，这个感觉有点丑
2. `GET /zoos/ID/animals：列出某个指定动物园的所有动物`，这是文中举的一个例子，要查某个表里某个 id 关联的其它表的数据，需要把 id 放在接口地址上，这样感觉很不好看，前端处理起来也很麻烦。
我们目前后端基本就是只用 GET 和 POST，甚至直接所有 POST 一把梭。
想知道各位都是怎么写的，是否有实践过 RESTful 的？以及实际效果怎么样？是否有很多槽点？你觉得哪种方式更好？
1. GET 方式参数都拼在 url 上，但是有时候一个接口甚至会携带十几个参数，比如我们现在的后台管理的一些列表就是，这个感觉有点丑
2. `GET /zoos/ID/animals：列出某个指定动物园的所有动物`，这是文中举的一个例子，要查某个表里某个 id 关联的其它表的数据，需要把 id 放在接口地址上，这样感觉很不好看，前端处理起来也很麻烦。
我们目前后端基本就是只用 GET 和 POST，甚至直接所有 POST 一把梭。
想知道各位都是怎么写的，是否有实践过 RESTful 的？以及实际效果怎么样？是否有很多槽点？你觉得哪种方式更好？
 |
1
dzdh 2021-07-14 09:49:15 +08:00
1.也没说 rest 就不准带参数了啊，不都是 filter 么
2.前端不是应该有封装的统一 request 库么, api 里留占位符啊，反而更清晰了吧 req.getAnimals(id) getAnimals (id) { req.get('/zoos/{id}/animals', {id:33}).filter({}).then(... |
 |
2
tabris17 2021-07-14 09:56:50 +08:00
复杂查询那就 GraphQL 咯
|
 |
3
Rwing 2021-07-14 10:06:16 +08:00
|
 |
4
daguaochengtang OP @dzdh
1. 你说的 filter 就是我说的查询字符串啊,`?name=xxx&limit=10`，遮掩的参数多了，url 会很长 2. 相比于 rest，一把梭的写法是这样的：getAnimal() {req.get('/getAnimals', {zoosId: 1, animalId: 1})}，所有接口的写法都一个样子 不是在抱怨 rest，上面的两点是这个规范的特点导致的，但看起来也确实是缺点。 |
|
5
daguaochengtang OP @Rwing 额，好吧。我之前确实没在 v 站看到过类似的贴子
|
 |
6
baiyi 2021-07-14 10:20:19 +08:00
虽然从 HTTP 方法的语义角度来讲，POST 一把梭的设计也没有什么问题，但是我们在设计 HTTP API 的时候，还是要尽量选用合适的 HTTP 方法，这是 RESTful 设计风格带来的好处，一个 HTTP 请求过程中的所有组件都遵循着这些规则。
比如 GET，为什么都推荐查询要用 GET，除了 GET 本身的语义，也是因为浏览器等组件为 GET 方法提供的一些其他的机制，最典型的例子就是缓存。 回到问题：1. Get filter 参数过多，解决方案一般有两个：① 精简参数及 Value，比如用缩写代替完整表述，用“,”、":"表示分割等方法。② 创建 filter 资源，然后用 filterID 进行 GET 查询。这其实是一种争议很大的方法，用起来很麻烦，所以很多人不愿意用。 就我个人而言，我会尽量使用 ①、如果实在无法使用 ①，我可能在适当的场景下会使用 ② 问题 2：不好看是主观感受，前端处理麻烦是伪命题，如果前端觉得麻烦只是他没这么做过 |
 |
7
murmur 2021-07-14 10:23:21 +08:00
不遵循，根据经验我们的接口都不带重名的，如果没有数据限制，我们 get 和 post 都支持
|
 |
8
balabalaguguji 2021-07-14 10:28:27 +08:00
没必要，怎么方便怎么来，就一个接口而已。
|
 |
9
teekgeek 2021-07-14 10:41:38 +08:00
目前我看到的
用 RESTful 规范 顶多也就 数据增删改查对应到四种 HTTP 请求方法 至于 url_path 和 query_string 这个比较混乱 所以每个接口 都会有一个说明文档 解释 请求的 URL 以及需要传的参数 参数是否必须 返回值 返回数据样例 等 这个接口说明 目前用的最多的是 swagger https://petstore.swagger.io/ 所以前后端分离 后端写接口 前端调用接口 必要的协商还是要有的，基本上就是每个接口的文档说明 |
 |
10
EPr2hh6LADQWqRVH 2021-07-14 10:46:32 +08:00
现在整个行业都在 HTTP 上面纠结，完全没必要，前后端分离之后，自己抽象 RPC 才是最适当的
|
 |
11
kop1989 2021-07-14 10:47:09 +08:00
RESTful 风格在我看来过于理想化了，目前的实际应用中优先级不高。
1 、RESTful 风格并没有显著降低 api 的沟通信息量。 2 、会出现特殊情况。（比如长参数的查询） 3 、比如楼上提及的针对不同请求方法的浏览器优化（比如 GET 请求的缓存机制），在业务上的优势很小，使用不当造成反效果则是灾难性的。 |
 |
12
Jooooooooo 2021-07-14 12:49:19 +08:00
有没有想过你为啥觉得遵守 RESTful 是好的实践?
是你见过什么实际项目严格遵守了 RESTful 很不错导致你也想试试吗? |
 |
13
kuangwinnie 2021-07-14 13:57:45 +08:00
当然呀，一个东西越显式越难犯错误。
|
 |
14
ajaxfunction 2021-07-14 23:50:33 +08:00
约束力太强，随着业务的发展，
总会有不遵循的地方，那就变成了为遵守而遵守了，反而更麻烦， 我对外提供的大部分 api 都是既支持 post 也支持 get，就是因为对接方水平参差不齐，光一个 put 就够就扯半天的。 |
Select Language