Rest 不使用OData语法的Web API数据分页

web api中有哪些选项可以指示返回的数据已分页，并且还有更多可用数据。 带有OData的ASP.Net Web API使用与以下类似的语法：

{
    "odata.metadata":"http://myapi.com/api/$metadata#MyResource","value":[
    {
        "ID":1,"Name":"foo"
    },
    ...
    {
        "ID":100,"Name":"bar"
    }
   ],"odata.nextLink":"http://myapi.com/api/MyResource?$skip=20"
}

---

是否有其他方法可以指示指向下一个/上一个数据“页面”的链接，而无需在结果周围使用元数据包装器。这可以通过使用自定义响应头来实现吗？

让我们退一步，想想WebAPI。WebAPI本质上是一种原始数据交付机制。它非常适合制作API，并将关注点的分离提升到一个相当好的高度（特别是消除UI关注点）

然而，使用WebAPI并不能真正改变您所面临的问题的核心。你在问“我想如何以高效的方式查询我的数据存储并将数据高效地返回给客户机？”在构建更传统的web应用程序时，你在这里的决定实际上与同样的问题平行

正如您所指出的，oData是返回此信息的一种方法。这里的好处是它是众所周知和定义明确的。关于这一主题的问题/博客/文章数量正在迅速增加。包装器不会增加任何有意义的开销

然而，oData绝不是你能做到这一点的唯一方式。自从软件显示搜索结果以来，我们不得不处理这个问题。在没有真正理解你的情况下，很难给你具体的建议。当我读到你的问题时，有一些问题冒了出来：

• 您的结果集是否庞大，但用户只能看到前一两个 页面
• 还是用户倾向于浏览所有结果
• 结果页面是否有限（比如每页20或50页）或100/1000
• 数据集是否快速移动，因此记录会随着用户的移动而添加 寻呼
• 您的结果集是否很短，添加重复的列是否可以接受
• 您对客户端是否有足够的控制权来执行带外操作—例如自定义HTTP头，或者只请求查询摘要的单独HTTP请求

---

根据您的需要，有数百种选择。我不知道你用什么作为数据存储，但我写了一篇文章。尽管从DB的角度来看，这里的问题非常密切。这可能会帮助你获得一些观点。

谢谢你的评论。作为一个背景，我使用Azure表存储作为我的数据存储，API请求可能返回具有相关开销的大型数据集。这就是我考虑分页的原因。我对检索数据的实现没有什么问题，我也不反对使用OData，但我想知道是否还有其他选择。仍然太笼统了，至少对我的大脑来说是这样：-）只需以适合您的形状返回数据即可。如果那是小田-太好了。如果它是一个列表，并且T有一个包含“CurrentRow”和“TotalRows”的字段，那么它也可以工作。如果是序列化为JSON的自定义嵌套对象，那就太好了。如果您希望带外使用HTTP头，也可以这样做。见鬼，你可以通过一块饼干来实现这一点。你有时间发明多少组合就有多少组合。另外，我关于SQL的观点并不是说你可能会有查询问题。相反，我的意思是，关于如何塑造数据的思考在DB级别和这个级别非常相似。搜索结果由两部分组成：元数据（总行、当前行/页）和实际数据。那么你是如何塑造它的呢？两个问题？一个问题？嵌套对象？费用是多少？等