我喜欢一些一些帮助处理一个奇怪的边缘情况与分页API我正在建设。

与许多api一样，这个api也会分页较大的结果。如果你查询/foos，你会得到100个结果(即foo #1-100)，和一个链接到/foos?Page =2，返回foo #101-200。

不幸的是，如果在API使用者进行下一次查询之前从数据集中删除了foo #10， /foos?Page =2将偏移100并返回foos #102-201。

这对于试图获取所有foo的API使用者来说是一个问题——他们不会收到foo #101。

处理这种情况的最佳实践是什么?我们希望使它尽可能的轻量级(即避免为API请求处理会话)。来自其他api的示例将非常感谢!

据我所知，每个单独的资源应该只有一个规范路径。那么在下面的例子中，好的URL模式是什么呢?

以公司的rest表示为例。在这个假设的例子中，每个公司拥有0个或多个部门，每个部门拥有0个或多个员工。

没有关联公司，一个部门就不能存在。

一个员工的存在离不开一个相关的部门。

现在我发现资源模式的自然表示是。

公司的集合-接受新公司的POST。获取整个集合。 /companies/{companyId}单个公司。接受GET, PUT和DELETE /companies/{companyId}/departments接受新项的POST。(在公司内部创建一个部门。) /公司/ {companyId} / {departmentId} / /部门 /公司/ / {departmentId} / {companyId} /部门员工 /公司/ {companyId} /部门/ {departmentId} /员工/ {empId}

考虑到每个部分的限制，我认为这是有意义的，如果嵌套有点深的话。

然而，如果我想列出(GET)所有公司的所有员工，我的困难就来了。

它的资源模式将最紧密地映射到/employees(所有员工的集合)

这是否意味着我应该有/employees/{empId}，因为如果是这样，那么就有两个URI来获得相同的资源?

或者可能整个模式应该是扁平的，但这意味着雇员是一个嵌套的顶级对象。

在基本层面/员工/?company={companyId}&department={deptId}返回与嵌套最深的模式完全相同的员工视图。

对于资源属于其他资源，但应该可以单独查询的URL模式，最佳实践是什么?

我想让我的RESTful API非常可预测。决定何时使用URI而不是使用查询参数分割数据的最佳实践是什么?

对我来说，支持分页、排序和分组的系统参数在'?'之后是有意义的。但是，像“status”和“region”这样的字段或其他属性如何划分您的集合呢?如果这些是查询参数，什么是关于知道什么时候使用路径参数的经验法则?

例如，您为用户/9运行一个GET请求，但没有id为#9的用户。 哪个是最佳响应码?

200好了 202年接受 204无内容 400错误请求 404未找到