私の知る限り、個々のリソースには正規パスが 1 つだけあるはずです。次の例では、適切な URL パターンは何でしょうか?
たとえば、企業の残りの表現を考えてみましょう。この架空の例では、各企業は0 個以上の部門を所有し、各部門は0 個以上の従業員を所有しています。
関連会社がなければ部門は存在できません。
従業員は、関連する部門がなければ存在できません。
今、私はリソース パターンの自然な表現が次のようになると考えています。
/companies企業のコレクション- 新しい企業の POST を受け入れます。コレクション全体を取得します。/companies/{companyId}個別の会社。GET、PUT、DELETE を受け入れます/companies/{companyId}/departments新しい項目の POST を受け入れます。(会社内に部門を作成します。)/companies/{companyId}/departments/{departmentId}//companies/{companyId}/departments/{departmentId}/employees/companies/{companyId}/departments/{departmentId}/employees/{empId}
各セクションの制約を考慮すると、少し深くネストしても意味があると感じます。
GETしかし、すべての企業のすべての従業員をリスト（ ）したい場合には困難が生じます。
そのためのリソースパターンは、/employees（全従業員の集合）に最も密接にマッピングされます。
/employees/{empId}つまり、同じリソースを取得するための URI が 2 つあるため、私もそうする必要があるということですか?
あるいは、スキーマ全体をフラット化する必要があるかもしれませんが、その場合、従業員はネストされたトップレベル オブジェクトになります。
基本レベルでは、/employees/?company={companyId}&department={deptId}最も深くネストされたパターンとまったく同じ従業員のビューを返します。
リソースが他のリソースによって所有されているが、個別にクエリ可能である必要があるURL パターンのベスト プラクティスは何ですか?
ベストアンサー1
私はネストされたエンドポイントとネストされていないエンドポイントの両方の設計戦略を試しました。次のことがわかりました。
ネストされたリソースに主キーがあり、その親の主キーを持っていない場合、システムでは実際には必要とされないにもかかわらず、ネストされた構造では主キーを取得する必要があります。
ネストされたエンドポイントには通常、冗長エンドポイントが必要です。言い換えると、部門間の従業員リストを取得するには、追加の /employees エンドポイントが必要になることがほとんどです。/employees がある場合、/companies/departments/employees によって具体的に何が得られるのでしょうか。
ネストされたエンドポイントは、それほどうまく進化しません。たとえば、今は従業員を検索する必要がないかもしれませんが、後で必要になる可能性があり、ネストされた構造がある場合は、別のエンドポイントを追加する以外に選択肢はありません。ネストされていない設計では、パラメーターを追加するだけなので、簡単です。
場合によっては、リソースに複数のタイプの親が存在することがあります。その結果、複数のエンドポイントがすべて同じリソースを返すことになります。
冗長なエンドポイントにより、ドキュメントの作成が難しくなり、API の学習も難しくなります。
つまり、ネストされていない設計により、より柔軟でシンプルなエンドポイント スキーマが可能になるようです。