我见过的有关 RESTful 架构的所有示例都处理单个记录。例如，一个 GET 请求mydomain.com/foo/53获取 foo 53 或 POST 到mydomain.com/foo创建一个新的 Foo.
但如果有多条记录呢？能够通过 id 请求一系列 Foo 或发布一组新的 Foo 通常，使用单个 API 请求比数十个单独的请求更有效。你会“超载”吗mydomain.com/foo处理单个或多个记录的请求？或者你会添加一个mydomain.com/foo-multiple处理多个 POST 和 GET？
我正在设计一个系统，可能需要一次获取许多记录（类似于mydomain.com/foo/53,54,66,86,87）但由于我还没有看到任何这样的例子，我想知道是否有一些我没有理解的 RESTful 架构使得这种方法“错误”。
不在单个请求中返回多个记录是有充分理由的，它的可缓存性和可扩展性较差。每当您想知道 REST 如何或为何发挥作用时，请查看网页。当您请求一个页面时，它会包含指向其他资源的链接，例如多个图像、CSS 文件、js 文件等。
虽然尝试通过单个请求抽取所有这些内容似乎更有效，但将它们全部视为单独的资源并允许 Web 服务器和保持活动连接来处理许多请求的可扩展性和缓存能力要高得多。资源高效。如果您将所有 css、javascript 和图像内联到可以代表整个页面的单个下载中，那么当您访问需要某些相同资源的另一个页面时，您必须再次下载它们，因为您没有正确引用它们浏览器第一次可以缓存作为单独的资源。
当您确实有代表多个资源列表的内容时，最安全的方法是让该列表只是各个资源的 url 列表，并分别获取每个资源，就像下面的网页一样flicker 包含页面上所有图像的 url，它不会尝试将它们全部内联到页面本身中。
当资源正确地允许缓存并单独引用时，缓存命中率可能会变得高得离谱，从而允许 Web 服务器处理更多负载，并允许在客户端和服务器之间缓存代理服务器，以防止请求甚至必须命中服务器。使用这种方法，网络运行良好，在认为这听起来很疯狂之前，请考虑一下。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
