在我看来，REST为基本的CRUD和列出资源提供了清晰明确的语义，但我没有看到如何处理大型资源列表的讨论。它不能扩展到在面向资源的体系结构中通过网络转储整个数据库表（想象一下拥有一百万客户的客户表！），特别是如果您只需要几个项目。因此，似乎应该存在一些语义来过滤，映射和减少服务器端的资源列表。
那么，您是否知道在REST中执行以下类型请求的任何尝试和真实的方法：
1）只检索资源的数量？
我可以想象做GET /api/customer?result=count
这通常是怎么做的？
我还可以想象修改URL（例如/api/count/customer或/api/customer/count），但这似乎要么打破资源路径的连续性，要么在预期的ID字段上造成丑陋的黑客攻击。
2）在服务器端过滤结果？
我可以想象使用查询参数，以特定于上下文的方式（例如GET /api/customer?country=US&state=TX）。
以灵活的方式执行它似乎很棘手，特别是如果您需要加入其他表（例如，获取在过去6个月内购买的客户）。
我可以想象使用HTTP OPTIONS 方法返回一个JSON字符串，指定可能的过滤器及其可能的值。
有没有人尝试过这种事情？
如果是这样，您获得了多么复杂（例如，检索年龄为18至45岁的女性客户在Massachussetts等购买的物品）？
3）映射到只获取一组有限的字段或从连接的表中添加字段？
4）比计数更复杂的减少（例如平均值，总和等）？
编辑：为了澄清，我对如何制定请求感兴趣，而不是如何在服务器端实现它。
答案 0 :(得分：1)
我认为你的问题的答案是OData！ OData是用于查询和与信息交互的通用协议。 OData基于REST，但扩展了语义，包括类似于SQL的程序化元素。
OData并不总是基于URL，因为它在某些情况下使用JSON有效负载。但它是一个标准（OASIS），所以它很好地结构化并得到许多API的支持。
一些一般性链接：
答案 1 :(得分：1)
在GET请求中处理大数据集的最常用方法是（afaict）：
1）分页。请求类似GET /api/customer?country=US&state=TX&firstResult=0&maxResults=50。通过这种方式，客户可以自由选择所需数据块的大小（这通常对基于UI的客户端有用）。
2）公开size服务，以便客户端在实际请求之前了解数据集的大小。服务会是这样的
GET /api/customer/size?country=US&state=TX
显然两者可以（和imho应该）一起使用，这样当客户（无论是移动设备还是网络或其他任何设备）用内容填充UI时，他可以选择什么是最好的数据块大小也基于整个数据集的大小（例如，为了避免为用户创建100页导航）。