複数の「所有者」が存在するREST APIリソース構造

Question

複数の所有者が同じリソースを使用する可能性があるREST APIをどのように構造化するのか苦労しています。たとえば、usersとorganizationsがあり、それぞれにimagesまたはlocationsのようなものがあるとします。別々の

POST /users/:userID/documents 
GET /users/:userID/documents/:id 
POST /org/:orgID/documents 
GET /org/:orgID/documents/:id 

長所：画像と場所は、私はそれ

別のエンドポイントについて移動する2つの基本的な方法を見ることができます...ユーザーと組織の両方で同じであるデータベースフィールドであり、エンドポイント：ロジックはきれいで、すべてが非常に明白です

エンドポイント間の締め切り：エンドポイント間にたくさんのコードコピーがあります。

共有エンドポイント：別のエンドポイントの

POST /documents 
GET /documents/:id 

長所：少なく、全体的なエンドポイントがありますが、以下のコードをコピー。別のエンドポイントの

短所：ロジックが乱雑取得は、実際に/documentsリソース内の新しいエンドポイントを作成せずに（リクエストとorgIDまたはuserIDを送って行くための最善の方法をIDK私はクエリ文字列を使用することができます。しかし、（それが間違っている場合はIDKを）それはちょうど...間違っている感じ

何かアドバイス？

Answer 1

それはすべてあなたのAPIのためのユースケースシナリオに依存します。

別のエンドポイントと間違って何もありません一般的に、ユーザ/組織とそれぞれの文書を要求することになる場合。また、コードの重複を意味する必要もありません。複数の場所で消費される、何らかの種類の共通のDocumentRepositoryをバックエンドに置くことができます。

要件は、単に/表示文書を検索している場合は、クエリ文字列は、あなたの最善の策かもしれません：

GET /documents?userId={userId}&organizationId={organizationId}