→ 主に2つの設計パターンが考えられます。メリット・デメリットを確認の上、ご検討ください。
複数の部署や企業で、1サービスを共有して利用することは可能です。
ただし、その場合は必要に応じて権限の設定を行い、閲覧可能な範囲を適切に制限する必要があります。
権限設定を行う対象（メディア、レビューなど）は複数存在しますが、ここでは主な操作であるコンテンツの入稿に関する設定パターンを紹介します。
異なる企業のコンテンツを、同じサービスで管理する場合、ロールの設定ミス等によって、データが共有されるリスクがあります。
このような運用を行う場合は、リスクをご検討の上、万が一共有されても問題ないコンテンツのみ、お取り扱いいただきますよう、お願いいたします。
設計パターン
主に以下の二つのパターンが考えられます。
- APIを分割して、API単位での閲覧制御を行う
- APIを共有した上で、コンテンツ単位での閲覧制御を行う
1. APIを分割して、API単位での閲覧制御を行う
組織ごとにAPIを作成して利用する方法です。
まず、「お知らせ（組織A）」「お知らせ（組織B）」のように、同様のスキーマ設定を持つAPIを複数作成します。
またユーザーに対して、「組織A」「組織B」のようなロールを作成し、付与します。
作成したロールは、APIの読み取り権限を、デフォルト権限を「オフ」、個別権限（対象のAPI）を「オン」に設定します。
▼ デフォルト権限
▼ 個別権限
このように設定を行った場合、メンバーはロールで設定したAPIのみ管理画面に表示され、アクセスすることが可能となります。
この設計パターンのメリットとデメリットは以下の通りです。
- メリット
- APIごとに閲覧制御されるので、閲覧可能な範囲がシンプルで、わかりやすい
- デメリット
- APIを組織の数に合わせて作成する必要がある
- それぞれのAPIのデータを、まとめて取得して利用する場合に、ソート処理で複雑な実装が必要になる
2. APIを共有した上で、コンテンツ単位での閲覧制御を行う
APIを一つだけ作成し、複数の組織で共有して利用する方法です
まず「お知らせ」のような単一のAPIを作成します。
またユーザーに対して、「組織A」「組織B」のようなロールを作成し、付与します。
作成したロールは、コンテンツの読み取り権限を、デフォルト権限を「オフ」、個別権限（対象のAPI）を「このロールのメンバーが作成したコンテンツのみ」に設定します。
▼ デフォルト権限
▼ 個別権限
このように設定を行った場合、お知らせAPIは、どちらのロールのメンバーも表示されますが、表示されるコンテンツが、同じロールのメンバーが作成したコンテンツのみに制限されます。
この設計パターンのメリットとデメリットは以下の通りです。
- メリット
- APIの作成数が1つで良いため、組織数の増加に対応しやすい
- 1つのAPIへのアクセスで、複数組織のコンテンツをまとめて取得できる
- デメリット
- 同じAPIの中で閲覧できる範囲が異なるため、閲覧可能な範囲がわかりづらい
- データの初期登録時に、コンテンツ作成者を、コンテンツを管理するロールのメンバーに付け替える必要がある
- 部署移動や退職などに応じて、コンテンツの作成者を変更する必要がある