23

現在、REST Http API を設計しています。(HATEOAS を使用して、クライアントを「シンプル」にし、API に何をすべきかを指示させる代わりに、クライアントが複雑なことをするのを避けるため...)

アプリの社会的特性により、アプリケーションとやり取りするには、ユーザーを認証する必要があり、各ユーザーはデータの「ビュー」がわずかに異なります。例としてツイッターを取り上げます。誰にとっても簡単です。

ユーザーを認証するには、簡単な OAuth を使用します。

したがって、クライアント (ios アプリ...) では、ランダムなユーザーがユーザーのリストを表示する可能性があります。

Adrien: Following
John:   Not Following
Rambo:  Not Following

また、別のユーザーは次のように表示される可能性があります。

Adrien: Following
John:   Not Following
Rambo:  Following

これを実現するための最初の解決策は、クライアント (oauth 用語では iphone/web/etc アプリ) が、認証されたユーザーがフォローしているすべてのユーザーのリストを取得し、クライアントがリストを表示するたびにそれぞれを比較することです。 「フォローしていない」または「フォロー中」を表示する必要があるかどうかを知るために、フォローしているユーザーのリストを持つユーザー。

要求/応答は次のようになります。

GET /users
Authorization: OAuth token...

[
  {"id": 1, "name": "Adrien"},
  {"id": 2, "name": "John"},
  {"id": 3, "name": "Rambo"}
]

と

GET /users/{myid}/following
Authorization: OAuth token...

[1, 3, 25, 1210, 9]

これはかなり、ステートレスのようです。良い。

ここで、クライアント開発者の作業を楽にし、認証されたユーザーに対する各ユーザーの関係をユーザー リストの応答に直接埋め込みたい場合はどうすればよいでしょうか。

GET /users
Authorization: OAuth token...

[
  {"id": 1, "name": "Adrien", "relationship": "Following"},
  {"id": 2, "name": "John", "relationship": "Not Following"},
  {"id": 3, "name": "Rambo", "relationship": "Following"}
]

だから、質問：

  • 「ステートレス」を破るように見えますが、本当にRESTステートレス制約を破っていますか?
  • 次に、API がこれを行うのは良い習慣だと思いますか?それとも悪い習慣だと思いますか?
4

5 に答える 5

16

ユーザーリストの応答に関係を必ず埋め込む必要があります。クライアントに計算を強制するのは悪い習慣です。

システムではなくインタラクションがステートレスであるため、これは REST のステートレスな制約を破るものではありません。サーバーはほとんどの場合、状態を保存して維持する必要があります。たとえば、サーバーは誰が誰をフォローしているかの状態を維持する必要があります。

最後に、Hypermedia As The Engine Of Application Stateの「状態」の部分を完全には理解していないと思います。基本的に、リソースはステート マシンです。リソースをGET使用すると、有効な状態遷移が提示され、応答にハイパーメディア コントロール (リンクとフォーム) が含まれます。クライアントがこれらのリソースの状態を変更できるのは、これらのリンクをたどってフォームを送信することです。

于 2012-07-21T23:22:51.570 に答える
13

応答本文にリレーションシップ タイプの記述を含めても、ステートレスな制約に違反することはありません。ステートレス制約は、Web サーバーが以前のリクエストに依存することなくリクエストに応答できることを意味します ( Tom、Jacobおよびkgbによって言及されているように)。

あなたが行っていることが「ベスト プラクティス」であるかどうかを私が判断する資格はありませんが、一般的に、Roy は API をステートレスにすることについて次の理由を挙げています (彼の論文のセクション 5.1.3 を参照してください)。人生の多くのことと同様に、トレードオフがあります。

ステートレス システムの問題

  • 要求はより大きくする必要がある場合があります。データはリクエスト間でサーバーに保存されないため、各リクエストに同じものを何度も含める必要がある場合があります。

  • ステートレス システムでは、サーバーはクライアントが状態を正しく維持することに依存しています。

ステートレス システムの利点

  • コンテンツだけに基づいて、リクエストが何を達成しようとしているのかがわかります。

  • 「部分的な障害から回復するタスクを容易にする」ため、信頼性。詳細については、ロイの論文で引用されている参考文献 133を参照してください。

  • スケーラビリティの向上。リクエスト間の状態の管理は、特に分散環境では非常に複雑になる可能性があります。ここで最初に思い浮かぶのは、ASP.NET InProc セッション状態です。これは、単一サーバー、単一プロセス インスタンスでは問題ありませんが、あまりうまくスケーリングしません。

RESTful リソース

また、ロイのリソースの定義によると、各ユーザーがデータのわずかに異なる「ビュー」を取得して、リソースをどのように定義していると思うかについて問題を提起します。Roy はリソースを、時間とともに変化するメンバーシップ関数として定義しています (論文のセクション 5.2.1.1 を参照)。上記で定義したユーザー リスト リソースは、時間と Authorization ヘッダーの両方によって異なります。/users を同時に要求する 2 つの異なるクライアントは、まったく異なる結果になる可能性があります。これにより、結果のキャッシュがより困難になります。

編集: HTTP の vary ヘッダーを使用すると、キャッシュできるようになります。

于 2012-07-23T15:08:09.253 に答える
4

ステートレス制約を破るユーザーに「relationship」プロパティを追加すると、リクエストに「/ follow」が含まれているときに追加すると、それも破られます。

「ステートレス」とは、他の要求/応答に依存する応答がないことを意味します。

HTTPはステートレスプロトコルですが、ユーザーに関する非常に多くのデータを要求/応答ヘッダーに格納できます（セッション/ Cookieについては話していません）。

于 2012-07-18T09:29:45.727 に答える
3

Roy Fieldings Architectural Styles and the Design of Network-based Software Architectures から:

3.4.3 Client-Stateless-Server (CSS)

The client-stateless-server style derives from client-server with the additional
constraint that no session state is allowed on the server component. 
Each request from client to server must contain all of the information necessary 
to understand the request, and cannot take advantage of any stored context on 
the server. Session state is kept entirely on the client.

リンク: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

したがって、エンティティ データを応答に直接埋め込んでも、ソリューションが非ステートレスになるわけではありません。

グッドプラクティスについて：

クライアントが何をすべきかを理解するための数字のリストよりも、実際にユーザーデータを提供する方がはるかに優れています。

ただし、各ユーザーのデータ量によっては、ユーザー リソースへのリンクのリストを提供し、「フォロー」関係も示すことを検討できます。その後、クライアントは必要なユーザーの詳細を取得できます。どのソリューションを選択するかは、クライアントが何を必要としているかに依存する必要があり、最終的にはいくつかのアプローチを使用することになります。

于 2012-07-21T23:35:30.907 に答える
1

「関係」情報を/usersリソースに埋め込むこととステートレス制約との間に相関関係は見られません。ですから問題はありません。

しかし、私はあなたが「資源の特定」の制約を破っていると主張します。

/Usersあなたと/Users私にとって、まったく異なる関係のセットを示すつもりです。これらは2つの異なるリソースであるため、異なるURIを持つ必要があると私は主張します。

ユーザーが誰であるかに基づいて表現を変更できるシナリオがいくつかありますが（たとえば、セキュリティ上の理由から）、この場合は私の好みにはあまりにも多くの変更です。

于 2012-08-29T12:53:52.887 に答える