3

次のような単純なリソースがあります。

/api/{configuration}/exhibitors/{id}

これは一般に、URL の構成部分の設定に応じてパブリック API です。

これは、認証されていないユーザーに返される場合があります。

{ "a" : "some value", "b" : "other value" }

しかし、管理者がログインしてこのリソースを取得したい場合、同じリソースでわずかに異なるデータが期待されます。

{ "a" : "some value", "C" : "admin only value" }

この管理者権限を検出して、同じ URL から別のコンテンツを返す必要がありますか?

それとも、誰向けで、コンテンツが異なる可能性があることを示す新しい URL を用意する必要がありますか?

/api/admin/{configuration}/exhibitors/{id}

私の考えでは、余分な URL は好きではありませんが、ユーザーに応じてコンテンツを変更する可能性がなければ、パブリック コンテンツをより簡単にキャッシュできるようになります。

admin 呼び出しがリソースの完全な公開バージョンと追加の管理者専用フィールドを取得できない理由はありませんが、私の例ではフィールド "b" はおそらく実際には必要ないので、むしろ管理者表現を使用したいと思います。少し軽くなりました。

4

2 に答える 2

1

認証されたユーザーとは、ユーザー ID とパスワードを提供した人、つまりログインした人だと思います。ユーザーがログインした後、ほとんどの REST アプリは Cookie に依存して、認証されたユーザーからのリクエストかどうかを判断する傾向があります。

理想的には、各ユーザーには独自のコンテキストが必要です。あるユーザーの /tmp/foo は、別のユーザーの /tmp/foo とは異なります。/public などで始まる URL で識別されるパブリック コンテンツを引き続き使用できます。

セキュリティ上の理由から、ユーザーの ID を URL の一部として漏らしたくはありません。また、ユーザー ID は、多くの場合、ユーザーの電子メールまたはアカウント番号になる傾向があります。

管理者は特殊なケースであり、バックエンド アーキテクチャによっては、管理者が他のユーザーの管理情報にアクセスできるようにするソリューションを実装することができます。

于 2013-07-08T15:32:48.773 に答える