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

[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 的？以及实际效果怎么样？是否有很多槽点？你觉得哪种方式更好？

[dzdh]

1.也没说 rest 就不准带参数了啊，不都是 filter 么

2.前端不是应该有封装的统一 request 库么, api 里留占位符啊，反而更清晰了吧

req.getAnimals(id)

getAnimals (id) { req.get('/zoos/{id}/animals', {id:33}).filter({}).then(...

[tabris17]

复杂查询那就 GraphQL 咯

[Rwing]

月经话题
https://www.google.com/search?q=site:v2ex.com/t%20RESTful

[daguaochengtang]

@dzdh
1. 你说的 filter 就是我说的查询字符串啊,`?name=xxx&limit=10`，遮掩的参数多了，url 会很长
2. 相比于 rest，一把梭的写法是这样的：getAnimal() {req.get('/getAnimals', {zoosId: 1, animalId: 1})}，所有接口的写法都一个样子

不是在抱怨 rest，上面的两点是这个规范的特点导致的，但看起来也确实是缺点。

[daguaochengtang]

@Rwing 额，好吧。我之前确实没在 v 站看到过类似的贴子

[FinnBai]

虽然从 HTTP 方法的语义角度来讲，POST 一把梭的设计也没有什么问题，但是我们在设计 HTTP API 的时候，还是要尽量选用合适的 HTTP 方法，这是 RESTful 设计风格带来的好处，一个 HTTP 请求过程中的所有组件都遵循着这些规则。
比如 GET，为什么都推荐查询要用 GET，除了 GET 本身的语义，也是因为浏览器等组件为 GET 方法提供的一些其他的机制，最典型的例子就是缓存。

回到问题：1. Get filter 参数过多，解决方案一般有两个：① 精简参数及 Value，比如用缩写代替完整表述，用“,”、":"表示分割等方法。② 创建 filter 资源，然后用 filterID 进行 GET 查询。这其实是一种争议很大的方法，用起来很麻烦，所以很多人不愿意用。
就我个人而言，我会尽量使用 ①、如果实在无法使用 ①，我可能在适当的场景下会使用 ②

问题 2：不好看是主观感受，前端处理麻烦是伪命题，如果前端觉得麻烦只是他没这么做过

[murmur]

不遵循，根据经验我们的接口都不带重名的，如果没有数据限制，我们 get 和 post 都支持

[balabalaguguji]

没必要，怎么方便怎么来，就一个接口而已。

[teekgeek]

目前我看到的
用 RESTful 规范 顶多也就
数据增删改查对应到四种 HTTP 请求方法

至于 url_path 和 query_string
这个比较混乱

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

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

所以前后端分离
后端写接口 前端调用接口
必要的协商还是要有的，基本上就是每个接口的文档说明

[EPr2hh6LADQWqRVH]

现在整个行业都在 HTTP 上面纠结，完全没必要，前后端分离之后，自己抽象 RPC 才是最适当的

[kop1989]

RESTful 风格在我看来过于理想化了，目前的实际应用中优先级不高。

1 、RESTful 风格并没有显著降低 api 的沟通信息量。
2 、会出现特殊情况。（比如长参数的查询）
3 、比如楼上提及的针对不同请求方法的浏览器优化（比如 GET 请求的缓存机制），在业务上的优势很小，使用不当造成反效果则是灾难性的。

[Jooooooooo]

有没有想过你为啥觉得遵守 RESTful 是好的实践?

是你见过什么实际项目严格遵守了 RESTful 很不错导致你也想试试吗?

[kuangwinnie]

当然呀，一个东西越显式越难犯错误。

[ajaxfunction]

约束力太强，随着业务的发展，
总会有不遵循的地方，那就变成了为遵守而遵守了，反而更麻烦，

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