4

私はハイパーメディア API、はい、RESTful API をハイパーテキスト制約付きで設計しています。

システムの各ユーザーは、独自の資格情報を使用してシステムにアクセスするため、処理するすべての要求が認証および承認されます。通常、各ユーザーは特定の資格情報を持っているため、コレクションごとに異なる権限 (なし、読み取り、読み取り/書き込みなど) を持つことができます。

クライアントに、それが開始する 1 つの URI を用意する必要があります。これはおそらく、atom サービス ドキュメントか、atom コレクションの階層 (ドラフトの atom 階層拡張) になります。

私の質問は、基本的に、ユーザーは同じ URI に対して異なる表現を表示する必要がありますか?それとも、ユーザーはアクセス許可に基づいて異なる URI にリダイレクトされるべきですか?

例: ユーザー A とユーザー B は、システム内で異なる権限を持っています。同じ開始 URI に、異なる資格情報でログインします。正常な応答は、次の 2 つのいずれかになります。

  1. 200 OK、ユーザー A は同じ URI でユーザー B とは異なるものを見ます
  2. 302 (または他のリダイレクト) 各ユーザーを /endpoint/userA (ユーザーが所有) などに

リソースはクライアントによってのみキャッシュされ、仲介者によってはキャッシュされないため、キャッシュ可能性のトレードオフはもちろん最小限ですが、可視性にもトレードオフがあります (URI には (認証された) ユーザー ID が含まれます)。最後に、ユーザー A (またはスーパー ユーザー) がユーザー B が見ているものを見ることができるようにする将来の可能性があります。

Twitter や Facebook が何をしているのかを尋ねているのではなく、REST の実践者がこれについて何と言っているかに興味があります。

4

3 に答える 3

1

個人的には、これを行うのは非常に難しいと思います。コンテンツがどれだけ変更されるかによると思います。違いがいくつかの余分な詳細の省略である場合、私はおそらくそれをユーザーに基づいて異なる単一のリソースとして扱います.

ただし、違いがより重要になり始めたら、別のリソースを作成することを検討します。私はまだ、特定のユーザーに固有のリソースを作成しないようにしています。おそらく、特定のリソースに対して、コンテンツのレベルが異なる一連のサブリソースを作成できます。例えば

/Customer/123?accesslevel=low
/Customer/123?accesslevel=medium
/Customer/123?accesslevel=high

この方法と 302 の組み合わせで十分な場合もあります。より複雑なケースでは、複数のクエリ文字列パラメーターを使用できます。

/Employee/123?SocialSecurityNo=yes&SalaryInfo=yes

この質問に対する簡単な答えはないと思います。答えはほとんどのトリッキーな REST シナリオに似ていると思います: 制約に違反しない限り、ソリューションは好きなだけ創造的にすることができます :-)

于 2010-07-12T01:45:07.447 に答える
0

オプション 1、200 で応答することは許容される REST 応答であり、オプション 2 よりもユーザー フレンドリーです。

Google Data API は、ユーザー サービスに加えて適切な REST 実装を提供し、オプション 1 を実装します。たとえば、Google Calendar Data APIを使用すると、ユーザーはhttp://wwwで HTTP GET 要求を実行することにより、ユーザー自身のフィードを照会できます。 .google.com/calendar/feeds/default/private/full .

于 2010-07-11T22:53:58.817 に答える