RESTfulな設計：子リソースを作成するためのベストプラクティス

Question

シナリオ：

私は0..N子リソース、Barを持っているいくつかのリソース、Fooを、持っています。

endpoint- http://resource/fooあり - 親サーバー上ではFooの新しいインスタンスを作成するために、すべてのFooリソースとPOSTのリストを取得するためにGETをサポートしています。

endpoint- http://resource/foo/:fooIdがあります： - Fooリソースを削除するFooリソース、およびDELETEを更新するFooリソース、PATCHをフェッチするGETをサポートしています。

endpoint- http://resource/foo/:fooId:/barあり

- 指定Foo上のすべてのBarリソースのリストを取得するためにGETをサポートし、POSTが与えられたのFooにBarの新しいインスタンスを作成します。

は直接、いくつかのBar子供とFooを作成POSThttp://resource/fooへの支援は、万一、または子の作成はのみFooの初期作成後http://resource/foo/:fooId:/barに明確な追加POSTsによってサポートされる必要がありますか？

Answer 1

残念なことに、このような質問には、ビジネスドメインと、APIが実行している環境（パフォーマンス、公開可用性、標準、既存のエンドポイントの設計方法など）と他の膨大なリスト要因。しかし、実際の問題を解決するためのコードであれば、ビジネス上の観点から開始することは良いことです。あなたはyouselfに次の質問尋ねるで始めることができ

：

• が接続されているすべてのBarずに理にかなってFoo（現実世界のエンティティとして）していますか？

か何かのように：

は創造の瞬間FooのオプションBarですか？

それがオプションの場合は、Barをサブリソースとして残し、コレクション/インスタンスをBarと別々に扱います。たとえば、halを使用して埋め込みリソースとしてBarを追加すると、それは非常にRESTfulになり、親子関係が透過的になります。リソースを可能な限りシンプルにし、できるだけ結合しないことは、REST apiのための良い戦略です。