一些通用的restful api设计问题

Question

几个通用设计问题：

1. 在这里举个例子：

https://developers.google.com/+/api/latest/activities/list#nextPageToken

为什么服务器会返回一个令牌来检索下一个分页结果？这不是打破了无国籍的想法吗？

为什么不只传递一个像 LIMIT name=value 这样的 MySQL 作为参数呢？服务器现在必须返回我想的页数......我错过了什么？

1. 我读过很多书，但很感兴趣：

REST Web Services API Design

第二个回复，提供以下例子。

GET http://api.domain.com/user/<id>
GET http://api.domain.com/users
PUT http://api.domain.com/user/<id>
POST http://api.domain.com/users
DELETE http://api.domain.com/user/<id>

有道理，但为什么有两个复数资源？不能假设如果“用户”被查询并且是 NULL 或者没有提供“全部”是预期的吗？ POST也一样？如果复数是为了提高可读性 - 为什么没有用于 DELETE 的“用户”资源？

归根结底，我将 REST 理解为...表示单个资源 - 使用 HTTP 动词（GET、PUT、POST、DELETE）从本质上管理该资源 - 类似于 CRUD。

编辑 |最后我还想问一下为什么 Google API 在 URI 中发送 API 版本而不是使用 HTTP 标头？有原因吗？为了向后兼容老客户？

评论？

Answer 1

为什么服务器会返回一个令牌来检索下一个分页结果？这不是打破了无国籍的想法吗？

对分页结果集使用这种机制是完全标准的，不会破坏无状态的想法。请考虑以下示例。

假设GET /users?after=<after>（其中after 是可选的）应该以分页方式返回所有用户的列表，例如每页

客户端发出的第一个请求是 GET /users，其响应可能如下所示（格式为 JSON）。

{
    "users": [ "alex", "bob", "carter", "dan" ]
    "more_after": "dan"
}

在此示例中，more_after 属性指定用户列表中可能还有更多用户。因此客户端随后请求GET /users?after=dan 并获得第二个响应，如下所示。

{
    "users": [ "edward", "frank" ]
}

more_after 属性的缺失表明这是用户的最后一页。

现在的问题是：“dan”标记用作页面分隔符是否破坏了我们想要的“无状态”属性？显然答案是否定的。服务器不必记住两个GET 请求之间的任何内容。没有会话的概念。任何需要在两个GET 请求之间持续存在的状态都只存在客户端——这是重要的区别。让客户端在对服务的调用之间保持状态是完全可以接受的，而且通常是必需的。