ユーザーと他のリソースとの多対多の関係のために、URIの設計にこだわっています。具体的には、さまざまなアプローチの結果を予測するのが困難です。
リソースタイプuser
およびwidget
(user
は登録済みユーザーを表します)を指定すると、認証済み(ログイン済み)ユーザーはすべてのウィジェットへの書き込みアクセス権を持ち、ゲストは読み取りアクセス権を持ちます。また、ユーザーとウィジェットの関係には、データ(例:編集の数)があり、理想的にはゲストが読み取れる(したがってaddressable)必要があります(および 以下 、他のユーザー)。例では、わかりやすくするために一意の識別子に整数を使用しています。
ゲストは、ウィジェット#12を次の場所で表示できます。
/widgets/12
認証済みユーザー#34がウィジェット#12の読み取り/書き込みを行い、オプションでゲストが2つの間のリレーショナルデータを読み取るためのさまざまなURIの意味は何ですか? (包括的な答えを与えることを心配しないでください。特定のオプションに対する賛否両論も非常に価値があります)。
/widgets/12
(ユーザーは認証に基づいて暗黙的であり、ゲストがユーザーとウィジェットの関係を指定する方法はありません)
/users/34/widgets/12
(関係の両側は、リソース間の明示的、暗黙的な階層)
/users/34/widgets/12 and /widgets/12/users/34
(同じ、階層なし)
/user-widget/34,12
(リソースとしての関係、明示的ですが、ユーザーが知る必要がある以上の関係)
詳細を提供したり、他の人のURIの提案を追加したりできます。何か追加したい場合はコメントしてください。
ウィジェットにアクセスするためのURLは、すべてのユーザーで同じでなければなりません。表示するものやユーザーが持つ機能の制御は、ユーザーIDに依存します。ユーザーIDは、たとえばセッション変数に保持できます。
そのため、widget/12がロードされると、Webページはセッション変数にユーザーIDが含まれているかどうかを確認し、そのアクセス許可を確認してから、それらのアクセス許可に基づいてページをフォーマットします。
/widgets/12
フォームを使用すると、ゲストはウィジェットを読むことができますか、またはユーザーは他のユーザーのウィジェットを読むことができますか?または、複数のフォームの実装を計画していますか?
個人的に、私は次のようなことをします:
/widget/id:12/user:665
/widget/12/665
/widget/12?user=665
最終的には、ユーザーが直接アクセスしたいものにならない限り、URLは重要ではありません。埋め込み可能なスクリプト、データフィード、または他の種類のサービスの場所にすぎない場合は、必要なURLを使用できます。その場合は、次のようなものを使用します。
/widget?id=12&uid=665
編集:
それはリソースであるため、/widget
の下でウィジェットを提供することを好みます。ユーザーとウィジェットの関係は、ウィジェットの種類によって暗示されていると思います。したがって、users
をパス階層に追加する必要はありません。
人々が特定のユーザーのウィジェットを閲覧できるようにしたい場合、/users/34/widgets/12
フォームが望ましいでしょう。
これが認証に関するものである場合、URLを介してまったく渡しません。 URLのユーザーIDを変更して、想定外のアクセス許可を取得するのを防ぐにはどうすればよいですか?