我见过的关于RESTful架构的所有示例都处理了一条记录。例如，GET请求mydomain.com/foo/53获取foo 53或POST mydomain.com/foo以创建新Foo。
但是多条记录呢？能够通过id请求一系列Foos或发布一系列新Foo通常会通过单个API请求而不是数十个单独请求更有效。你会“重载”mydomain.com/foo来处理单个或多个记录的请求吗？或者你会添加一个mydomain.com/foo-multiple来处理多个POST和GET吗？
我正在设计一个可能需要同时获取许多记录的系统（类似于mydomain.com/foo/53,54,66,86,87）但是因为我没有看到任何这方面的例子，我想知道我是否有什么东西我只是没有得到一个RESTful架构，使这种方法“错误”。
答案 0 :(得分：10)
有一个很好的理由不在单个请求中返回多个记录，它的缓存能力较低，可扩展性较差。任何时候你想知道REST应该如何或为什么起作用，看一下网页。当您请求页面时，它会显示指向其他资源的链接，例如多个图像，css文件，js文件等。
虽然尝试通过单个请求尝试并提取所有这些内容似乎更有效，但它具有更高的可扩展性和缓存能力，可以将它们全部视为单独的资源，并允许Web服务器和保持活动连接来处理要求许多资源有效。如果您将所有css，javascript和图像内联到可以代表整个页面的单个下载中，当您访问需要某些相同资源的另一个页面时，您必须再次下载它们，因为您没有正确引用它们作为个人资源，浏览器第一次可以缓存。
如果你确实拥有代表多个资源列表的东西，那么这样做的另一种方法就是让列表成为各个资源的URL列表，并分别获取每个资源的列表，就像说闪烁的网页包含页面上所有图像的网址，它不会尝试将它们全部内嵌到页面本身。
当资源正确地允许缓存并单独引用时，缓存命中率可能会非常高，允许Web服务器处理更多负载并允许客户端和服务器之间的缓存代理服务器以防止请求甚至不得不命中服务器。在认为这听起来很疯狂之前，网络很好地运用这种方法，想一想。
答案 1 :(得分：6)
虽然我没有看到您的方法存在任何本质上的错误，但对于您的API用户来说，希望foo记录具有任意ID似乎有点奇怪。我立即怀疑他们正在使用ID来表示一个不同的概念，例如，在上周创建的所有foo等等。如果这是他们正在做的事情，那么你应该暴露服务器上的该功能，而不是使用ID列表作为代理。
答案 2 :(得分：3)
这是一个古老的问题，但是，我正在为那些可能在寻找答案时落在这里的人写这篇文章。
申请请求ID指定的多个记录有很多正当理由，不需要，不需要任何逻辑，如“上周创建”或“在Date1和Date2之间创建”等。想象一下情况向用户显示网格/记录列表，他们可以手动选择多个记录进行进一步处理。
话虽如此，这里已经提出了许多解决方案： How to construct a REST API that takes an array of id's for the resources
然而，恕我直言，最佳解决方案是@nilesh在同一讨论中的解决方案： https://stackoverflow.com/a/32436345/134120
首先执行POST传递您想要获取的ID，服务器将返回批次ID，然后您使用该批次ID进行GET以获取所有记录。