是吗：
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 怎么办？
第二个似乎更好，因为没有粗略的 url，但我对休息的理解是 POST 应该进行更改，而不是幂等的。
那么这纯粹是一个语义问题，没有真正的“正确”方式吗？
die*_*ter 10
我会使用 POST，因为：
POST requests are never cached (by browser)
POST requests have no restrictions on data length
阅读更多内容：HTTP 方法：GET 与 POST
另外，POST、GET 都是在 REST 之前定义的。因此，对于某些只读请求（有时！）使用 POST 并不是什么丢人的事情。
编辑：
几年后，我必须修改我的答案。
今天我认为 GET 和 POST 都不是解决实际问题的好方法。至少，这里没有最终的解决方案，这取决于......
首先一些事实：
那么你一定要弄清楚，这个ID列表的来源是什么，ID是从哪里来的？这当然有一些商业案例。
我会尝试将 ID 的来源或创建 ID 的逻辑移至后端。完成此操作后，REST 端点“获取多个资源”就不再需要。
因此，消息是，当您无法使用时，请尝试消除此类 REST 调用的需要GET
没有一种“正确”的方式，它实际上取决于 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，则 POST 可以是幂等的。只是 PUT 应该始终是幂等的，而 POST 可以不这样。只需正确记录端点。
您可以允许接受来自 GET 和 POST 的 ID。然后根据发送的 ID 数量，客户端可以选择其中之一。只需正确记录即可。
指导原则是您的 API 的易用性和一致性。了解制作 API 是一个用户体验问题。
| 归档时间： |
|
| 查看次数： |
5660 次 |
| 最近记录： |