私はRESTAPIを書いていますが、フィードバックが必要です。Itemsというリソースが1つあります。パブリックにアクセスするか、プライベートにすることができます（ユーザーのみが表示できます）。私の最初のアイデアは、パブリックアイテムが存在する/ Root / ItemsなどのパブリックアイテムへのURLと、プライベートアイテムが存在する/ Root / User/Itemsなどの他のURLを配置することでした。アイテムを別のユーザーにリンクできるため、アイテムを更新する権限があります。/ Root / User / Operator / Items ....のようなものですが、作成しているアドレスが多すぎることに気付きます。
ユーザーごとに出力が異なるため、すべてのアイテムをde / Root /Itemsurl内に配置するというアイデアは好きではありません。また、/ Root / user / Items内にのみ配置すると、すべての公開アイテム（任意のユーザーに属する可能性があります）を一覧表示することはできません。
どうすればそれを設計できますか？
RESTful アーキテクチャでは、期待どおり HTTP を使用する場合、すべての「もの」に URI である 1 つの識別子が必要です。あなたの場合、すべてのアイテムには URI が 1 つだけ必要です。
私の最初のアイデアは、パブリック アイテムが存在する /Root/Items のようなパブリック アイテムへの URL と、プライベート アイテムが存在する /Root/User/Items のような他の URL を配置することでした。
アイテムのコレクションを返すコレクション リソースについて話しているだけではないと思います。単品のリソースもあると思います。単一のアイテムの URI は、スキーム内で /Root/Items/42 または /Root/User/Items/23 になります。
必要な承認を行うのに役立つ場合は、パブリック アイテムとプライベート アイテムに異なる URI スキームを使用できます。とにかく、REST では URI は重要ではありませんでした。URI は常に不透明であると見なされるべきです。パブリック アイテムとプライベート アイテムに異なるスキームを使用する場合は、パブリック アイテムが決してプライベートにならないようにする必要があります。その場合、アイテムの URI が変更されます。これは、データベース内の行の主キーを変更する場合と同じです。識別子は変更しないでください。パブリック アイテムとプライベート アイテムに異なる URI スキームを使用している場合に行っていることは、アイテムのプライバシー レベルを識別子にエンコードすることです。問題のドメインでこれが許可されていれば問題ありません。
アイテムは別のユーザーにリンクできるため、アイテムを更新する権限があります。/Root/User/Operator/Items のようなもの .... しかし、作成したアドレスが多すぎることに気付きました。
これは、アイテムのプライバシー レベルを変更したいように思えます。前に述べたように、1 つのアイテムには変更されない URI が 1 つだけある必要があります。コレクション リソースについて話している場合は、スキームがそうである可能性があります。ここで何を意味するのかわかりません。
最後に: 必要なのは認証と承認です。URI に関係なく、ユーザーが別のユーザーのプライベート アイテムにアクセスしたい場合は、403 Forbidden を返す必要があります。