你们平时写接口会遵循 RESTful API 吗?

2021-07-14 09:43:19 +08:00
 daguaochengtang
是这样,我是前端,但是最近打算学写 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 的?以及实际效果怎么样?是否有很多槽点?你觉得哪种方式更好?
2990 次点击
所在节点    问与答
14 条回复
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(...
tabris17
2021-07-14 09:56:50 +08:00
复杂查询那就 GraphQL 咯
Rwing
2021-07-14 10:06:16 +08:00
daguaochengtang
2021-07-14 10:11:11 +08:00
@dzdh
1. 你说的 filter 就是我说的查询字符串啊,`?name=xxx&limit=10`,遮掩的参数多了,url 会很长
2. 相比于 rest,一把梭的写法是这样的:getAnimal() {req.get('/getAnimals', {zoosId: 1, animalId: 1})},所有接口的写法都一个样子

不是在抱怨 rest,上面的两点是这个规范的特点导致的,但看起来也确实是缺点。
daguaochengtang
2021-07-14 10:14:32 +08:00
@Rwing 额,好吧。我之前确实没在 v 站看到过类似的贴子
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:不好看是主观感受,前端处理麻烦是伪命题,如果前端觉得麻烦只是他没这么做过
murmur
2021-07-14 10:23:21 +08:00
不遵循,根据经验我们的接口都不带重名的,如果没有数据限制,我们 get 和 post 都支持
balabalaguguji
2021-07-14 10:28:27 +08:00
没必要,怎么方便怎么来,就一个接口而已。
teekgeek
2021-07-14 10:41:38 +08:00
目前我看到的
用 RESTful 规范 顶多也就
数据增删改查对应到四种 HTTP 请求方法

至于 url_path 和 query_string
这个比较混乱

所以每个接口 都会有一个说明文档
解释 请求的 URL 以及需要传的参数 参数是否必须
返回值 返回数据样例


这个接口说明 目前用的最多的是 swagger
https://petstore.swagger.io/

所以前后端分离
后端写接口 前端调用接口
必要的协商还是要有的,基本上就是每个接口的文档说明
EPr2hh6LADQWqRVH
2021-07-14 10:46:32 +08:00
现在整个行业都在 HTTP 上面纠结,完全没必要,前后端分离之后,自己抽象 RPC 才是最适当的
kop1989
2021-07-14 10:47:09 +08:00
RESTful 风格在我看来过于理想化了,目前的实际应用中优先级不高。

1 、RESTful 风格并没有显著降低 api 的沟通信息量。
2 、会出现特殊情况。(比如长参数的查询)
3 、比如楼上提及的针对不同请求方法的浏览器优化(比如 GET 请求的缓存机制),在业务上的优势很小,使用不当造成反效果则是灾难性的。
Jooooooooo
2021-07-14 12:49:19 +08:00
有没有想过你为啥觉得遵守 RESTful 是好的实践?

是你见过什么实际项目严格遵守了 RESTful 很不错导致你也想试试吗?
kuangwinnie
2021-07-14 13:57:45 +08:00
当然呀,一个东西越显式越难犯错误。
ajaxfunction
2021-07-14 23:50:33 +08:00
约束力太强,随着业务的发展,
总会有不遵循的地方,那就变成了为遵守而遵守了,反而更麻烦,

我对外提供的大部分 api 都是既支持 post 也支持 get,就是因为对接方水平参差不齐,光一个 put 就够就扯半天的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/789400

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX