REST APIの作成を進めており、現在、次の問題が発生しています。
Foo
最初のリソースです。CRUD操作は/foo/
URI を介して適用できます。Bar
2番目のリソースです。CRUD操作は/bar/
URI を介して適用できます。- Every
Foo
は0または1に関連付けられていますBar
。のBar
サブリソースとして扱わないのFoo
はBar
、複数Foo
のs 間で同じインスタンスを共有できるためです。ですから、の代わりに独立したURI経由でアクセスする方がよいと考えました/foo/[id]/bar
。
私の問題は、かなりの場合、インスタンスを要求するクライアントがFoo
関連するインスタンスにも関心があることBar
です。現在、これは、1つではなく2つのクエリを実行する必要があることを意味します。1つのクエリで両方のオブジェクトを取得できる方法を紹介したいのですが、そのためのAPIをモデル化する方法がわかりません。これまでに思いついたこと:
- 次のようなクエリパラメータを導入できます
/foo/[id]?include_bar=true
。このアプローチの問題は、応答のリソース表現(JSON構造など)が異なるように見える必要がある(たとえば、{ foo: ..., bar: ... }
単にシリアライズされたものではなく、コンテナーなどFoo
)ため、Foo
リソースエンドポイントが「異種」になることです。それは良いことではないと思います。をクエリする場合/foo
、クライアントはクエリパラメータに関係なく、常に同じリソース表現(構造)を取得する必要があります。 - もう1つのアイデアは、新しい読み取り専用エンドポイントを導入すること
/fooandbar/[foo-id]
です。この場合、のような表現を返すことは問題ありません。これ{ foo: ..., bar: ... }
は、fooandbar
リソースの「公式」表現にすぎないためです。ただし、そのようなヘルパーエンドポイントが本当にRESTfulであるかどうかはわかりません(これが質問のタイトルに「can」と書いた理由です。もちろん、技術的には可能ですが、それが良いアイデアかどうかはわかりません)。
どう思いますか?他の可能性はありますか?
フーとバーの関係の用語は何ですか?BarはFooの親だと言えますか?
—
Nathan Merrill
は
—
ceran 2016年
Bar
、に関連付けられていないと存在できませんFoo
。ただし、上で書いたように、複数Foo
のが同じを共有する可能性がありますBar
。アソシエートFoo
なしでを作成できるはずなBar
のでBar
、親として扱われるべきではないと思います。
私は、ドメインモデルの関係を直接URIに変換し、リソースをドメインエンティティと同等にすることによって、私が経験したいくつかの問題を経験していると思います。それは興味ありますREST APIはハイパーテキスト主導型でなければなりません。4番目のポイントへの特別な注意
—
Laiv