基于ID批量获取记录的REST API最优实现方案咨询

现有记录示例 #

[
 {
    "id": 1,
    "name": "Chris",
    "class": "x",
    "year": 3
 },
 {
    "id": 2,
    "name": "John",
    "class": "y",
    "year": 4
 }
]

需求与可选方案 #

我希望通过单次API调用，基于ID批量获取多条记录，目前有两种实现方式：

方案1：携带多个ID的GET请求 #

GET https://api.com/school/names?id=1,2,3

方案2：提交ID列表的POST请求 #

POST https://api.com/school/names?action=get

请求体：

{
  "id1": 1,
  "id2": 2,
  "id3": 3
}

注：我们不存在URL长度超限问题（不会超过2048字符限制），且观察到不少公开API同时采用这两种方式，但我认为用POST请求获取数据可能违反REST原则，希望专家推荐该场景下的最佳实现方案，并说明相较于另一方案的优势。

最佳方案推荐：用GET请求就对了 #

在你这个场景里，强烈推荐用携带多个ID的GET请求，最关键的原因是它完全贴合REST设计原则，而且相比POST方案有不少实打实的优势：

1. 语义更合规：GET的本来用途就是“获取资源”，批量查记录本质还是资源查询，用GET完全说得通；但POST的语义一般是“创建资源”或者执行那种重复调用会有不同结果的操作，用它来查数据，等于把HTTP方法的语义搞混了，明显违反REST的核心思路。

2. 自带缓存buff：GET请求是幂等的——多次调用结果完全一样，浏览器、CDN或者中间件能自动缓存它的响应，不用每次都去服务器查，既能减轻服务器压力，用户那边加载也更快；POST请求默认不会被缓存，根本吃不到这个优化红利。

3. 调试和追溯更方便：GET的参数直接写在URL里，调试的时候复制URL就能在浏览器或者工具里跑，排查问题特别省事；POST的参数藏在请求体里，调试还得额外构造请求体，步骤麻烦多了。

4. 兼容性拉满：所有HTTP客户端对GET请求的支持都很完善，不用额外处理请求体；有些简单客户端或者代理对POST带请求体的情况可能有限制，容易出问题。

虽然不少公开API同时给两种方式，但你既然没有URL长度的顾虑，选GET肯定是更合理的。

内容的提问来源于stack exchange，提问作者Sathish