是吗：
GET api/stuff?ids[]=123&ids[]=456&ids[]=789&ids[]=101112&etc...
是吗：
POST api/stuff/batch
body: ids: [123, 456, 789, 101112, etc]
?
第一个在语义上似乎是正确的，但除了具有令人难以置信的粗略 URL 之外，还有消息来源说 get 的长度可能存在限制，那么如果我有大量的 id 怎么办？
第二个似乎更好，因为没有总网址，但我对休息的理解是 POST 应该进行更改，而不是幂等的..
那么这纯粹是一个语义问题，没有真正的“正确”方式吗？
【问题讨论】：
标签： rest api-design
没有一种“正确”的方式，它实际上取决于 REST 服务器的特定要求。但是，对于带有查询字符串的 GET，它可能看起来更像这样：
GET api/stuff?ids=123+456+789+101112+...
或者像这样：
GET api/stuff?ids=123,456,789,101112,...
或者这个：
GET api/stuff?ids=123|456|789|101112|...
服务器想要使用的任何分隔符。
【讨论】：
与 REST 中的许多东西一样，并不总是可以成为纯粹主义者。
一种解决方案是灵活定义资源是什么。那么，获取多个资源本身就是一种资源。
POST 可以是幂等的，如果这对您的 API 来说是最好的。只是 PUT 应该始终是幂等的，而 POST 可以不这样做。只需正确记录端点即可。
您可以允许接受来自 GET 和 POST 的 ID。然后根据发送的 ID 数量，客户端可以选择其中一个。只需正确记录即可。
指导原则是 API 的易用性和一致性。了解制作 API 是一个用户体验问题。
【讨论】：
我会使用 POST，因为：
POST requests are never cached (by browser)
POST requests have no restrictions on data length
阅读更多：HTTP Methods: GET vs. POST
还有 POST、GET 是在 REST 之前定义的。因此，对一些只读请求使用（有时！）POST 并不可耻。
编辑：
几年后，我必须修改我的答案。
今天我认为 GET 和 POST 都不是解决实际问题的好方法。至少，这里没有最终的解决方案，这取决于...
首先是一些事实：
那你一定要澄清一下，这个 ID 列表的来源是什么，ID 是从哪里来的？这当然有一些商业案例。
我会尝试将 ID 的来源或创建 ID 的逻辑移至后端。完成此操作后，REST 端点 “获取多个资源” 就不再需要了。
所以消息是，当你不能使用GET时，尽量消除对此类 REST 调用的需要
【讨论】：