[解決済み] RESTのネストされたリソースのベストプラクティスは何ですか？

質問

私が知る限り、個々のリソースには カノニカルは1つだけ のパスが必要です。 では、次の例では、どのようなURLパターンが良いのでしょうか？

例えば、会社のリスト表現を考えてみましょう。この仮想の例では、各企業が 所有 0以上の部門と各部門 所有 0人以上の従業員がいること。

A部門 存在しえない 関連する会社がない場合。

従業員 存在しえない 関連する部門がない場合。

今なら、リソースパターンの自然な表現が見つかりますね。

• /companies 企業の集合体 - 新しい会社のputを受け付けます。コレクション全体に対して取得する。
• /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} なぜなら、もしそうなら、同じリソースを取得するために2つのURIが存在することになるからです。

あるいは、スキーマ全体をフラット化すべきかもしれませんが、そうすると社員はネストしたトップレベルのオブジェクトになってしまいます。

基本的なレベルでは /employees/?company={companyId}&department={deptId} は、最も深くネストされたパターンとまったく同じ従業員のビューを返します。

URLパターンにおいて、リソースが 所有 は他のリソースに依存しているが、個別にクエリ可能であるべきですか？

どのように解決するのですか？

あなたが行ったことは正しいです。 一般に、同じリソースに対して多くのURIを指定することができます。

そして一般的には、アイテムに直接、あるいは何かのサブセットとしてアクセスする必要があるかもしれません - ですから、あなたの構造は理にかなっていると思います。

社員が部署でアクセスできるようになっただけで

company/{companyid}/department/{departmentid}/employees

会社の下でもアクセスできないわけではありません。

company/{companyid}/employees

その会社の社員を返してくれるのはどちらでしょう。 それは、消費者であるクライアントが何を必要としているかに依存するものです。

しかし、すべてのURLハンドラーが同じバッキングコードを使用してリクエストを満たすようにし、コードの重複がないようにしたいものです。