一些一般的寧靜API設計問題

Question

一些一般的設計問題：

1. 在此處給出示例：

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

服務器為什么要返回令牌以檢索下一個分頁結果？ 這不會破壞無狀態的想法嗎？

為什么不僅僅將LIMIT name = value之類的MySQL作為參數傳遞呢？ 服務器現在必須返回我猜想的頁面數...我缺少什么？

2. 我讀了很多書，但是這很有趣：

REST Web服務API設計

第二個答復提供以下示例。

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？ 如果使用復數形式是為了提高可讀性-為什么沒有用於刪除的“用戶”資源？

最終，我將REST理解為...表示單個資源-使用HTTP動詞（GET，PUT，POST，DELETE）從本質上管理該資源-與CRUD類似。

編輯| 最后，我還想問為什么Google API在URI中而不是使用HTTP標頭發送API版本？ 有什么原因嗎？ 與舊客戶向后兼容？

評論？

Answer 1

服務器為什么要返回令牌以檢索下一個分頁結果？ 這不會破壞無狀態的想法嗎？

對分頁結果集使用這種機制是完全標准的，並且不會破壞無狀態的想法。 考慮以下示例。

假設GET /users?after=<after> （其中after是可選的）應該以分頁方式返回所有用戶的列表，例如每頁<= 4。

客戶端發出的第一個請求是GET /users ，其響應可能類似於以下內容（格式為JSON）。

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

在此示例中， more_after屬性指定在用戶列表中可能還有更多用戶。 因此，客戶端隨后請求GET /users?after=dan並獲得第二個響應，如下所示。

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

如果缺少more_after屬性，則表示這是用戶的最后一頁。

現在的問題是：“ dan ”標記用作頁面分隔符是否破壞了我們想要的“ statelessness”屬性？ 顯然答案是否定的。 服務器不必記住兩個GET請求之間的任何內容。 沒有會議的概念。 需要在兩個GET請求之間保留的任何狀態都僅存在於客戶端 -這是重要的區別。 讓客戶端在調用服務之間保持狀態是完全可以接受的，並且經常是必須的。