请教大家一个问题，如何设计 HTTP API 接口？

[yongchiu]

现在做开发的时候遇到一个问题，需要将以前三个接口完成的功能整合到一个功能里来，对于 POST 类的请求可以整合到 body 里，里面是由多个 JSON 组成的一个大 JSON 数据，这样做主要是参考 Google 的做法。 对于 GET 类的请求应该如何设计呢，GET 请求一般不用 body ，怎么用一个比较好的方式把三个接口的参数整合到一起？

[rekulas]

直接拼接倒 url 或者 (如果有冲突)装入 json 整个作为一个参数?
反正作为 get 来说参数应该不多，如果参数太多还用 get ，感觉是有问题的

[rekulas]

现在还有个 GraphQL 的新概念，需要后端配合修改据说可以多个 api 整合但是会增加不少工作量没用过

[yongchiu]

@rekulas 这是一个查询类的请求，查询一些数据的信息，因此考虑使用 GET 方法比较合适；装入 json 是怎么做呢？ GET 请求能使用 JSON 吗？

[yongchiu]

@rekulas 主要是调用他人的 RPC 接口，RPC 只提供了两个接口，根据不同的参数返回不同的结果；因此 API 打算也按照 RPC 的接口进行设计，另一方面参考 Google 的 API 也是把多个接口的功能整合到了一个接口里面来

[rekulas]

api?{"req1param":{},"re2param":{}}
或考虑伪静态之类 api/{"req1param":{},"re2param":{}}

参数也可以编码一下

[bombless]

get 也是可以放 body 的，不过你要预先测试一下你的服务端是否支持。我后端用的是 springboot 那套是可以的

[Chad0000]

有时候没必要完全按 rest 建议来，我的所有 api 都是 post ，就不会有这个问题。

[kop1989]

可以拼在 URL 中，然后这个请求只有一个参数，其内容是 urlencode 过的、真正参数集合的序列化结果。

当然，要考虑超长，不过查询应该问题不大

[rekulas]

我也建议全部 post 来，rest 本身就不是一种足够完备的风格，如果全部机械式按 rest 设计只会带来更多麻烦不便

[iikebug]

我自己写的接口都是 post 的，管你什么方法，前端舒服的一批

[yongchiu]

@bombless 后端不支持带 body

[yongchiu]

@kop1989 这样的话，还是需要设计多个参数吧，把这些参数统一序列化传递给后端进行解析，是这个意思吗？

[yongchiu]

@rekulas 我感觉都定义成 POST 可能会更好一些

[lisongeee]

有时候挺纠结 get 还是 post ，不能要求每个人不是傻逼，还不如直接用 json-rpc ，统一的规范比什么都好

[zqli92]

一个建议：只用 get/post 方法，body 的数据结构可以看这个： https://hackertalk.net/post/202030390784430080