0

いくつかの一般的な設計上の質問:

  1. ここに例を示します。

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

次のページ分割された結果を取得するためにサーバーがトークンを返すのはなぜですか? これは、ステートレスであるという考えを壊しませんか?

パラメータとして LIMIT name=value のような MySQL を渡さないのはなぜですか? サーバーは、私が推測するページ数を返さなければなりません...何が欠けていますか?

  1. いろいろ読んだが、これは興味深かった：

REST Web サービス API 設計

2 番目の返信では、次の例を提供しています。

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>

理にかなっていますが、なぜ複数のリソースが 2 つあるのですか? 「ユーザー」が照会されて NULL であった場合、または「すべて」が意図されたものではない場合、想定できませんか? 同様に、POST? 複数形が読みやすさを向上させるためのものである場合、DELETE 用の「ユーザー」リソースがないのはなぜですか?

最終的に、私はRESTが単一のリソースの表現を意味することを理解しています-HTTP動詞（GET、PUT、POST、DELETE）を使用して、そのリソースを本質的に管理します-CRUDに似ています。

編集 | 最後に、Google API が HTTP ヘッダーを使用するのではなく、API バージョンを URI で送信するのはなぜですか? 理由はありますか？古いクライアントとの後方互換性のため?

コメント?

4

1 に答える 1

1

次のページ分割された結果を取得するためにサーバーがトークンを返すのはなぜですか? これは、ステートレスであるという考えを壊しませんか?

ページ分割された結果セットにこの種のメカニズムを使用することは完全に標準であり、ステートレスであるという考えを壊すことはありません。次の例を考えてみましょう。

GET /users?after=<after>(ここではafterオプションです) がページ分割された方法ですべてのユーザーのリストを返すことになっているとします。たとえば、1 ページあたり <= 4 です。

クライアントが行う最初の要求はGET /users、次のような応答 (JSON 形式) です。

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

この例では、more_afterプロパティは、ユーザー リストにまだユーザーが残っている可能性があることを示しています。したがって、クライアントGET /users?after=danは次のような 2 番目の応答を要求して取得します。

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

プロパティがないことは、more_afterこれがユーザーの最後のページであることを示します。

問題は次のとおりです。danページ セパレータとして使用された " " トークンは、必要な "ステートレス" プロパティを壊すものでしたか? 明らかに答えはノーです。GETサーバーは、2 つの要求の間で何も覚えておく必要はありません。セッションという概念はありません。GET2 つの要求の間で保持する必要がある状態は、クライアント側にのみ存在します。これが重要な違いです。クライアントがサービスへの呼び出し間で状態を維持することは、完全に受け入れられます (そして多くの場合、必須です)。

于 2013-04-08T02:21:20.543 に答える