私は個人的なプロジェクトのために最初のRESTAPIを構築しています（少なくとも試してみました）。
このプロジェクトには、playersと呼ばれるリソースがありteamます。REST API設計ルールブックによると、リソースはドキュメント またはストアのいずれかになり、これらの役割を可能な限り分離しておく必要があります。
teamそれでも、リソースにいくつかのメタデータを追加したいと思います。たとえば、teamが設立された日付です。それでは、このメタデータをチーム内のsのリスト（ストアにする）と一緒GET /teams/atlantaに返す（ドキュメントにする）ことはできますか？player
これは良い考えですか？もしそうなら、なぜですか？そうでない場合は、なぜそうではなく、これをよりよく解決する方法は？
REST APIを開発するためのルールがないことは知っていますが、優れたプラクティスがあり、それらを順守したいと思います。また、これが本当に私の最初のREST APIであるということではないので、もしあれば私の無知を許してください。
GET /teams/atlantaあなたが言及した創設日など、チームに関する情報だけを返送してから、GET /teams/atlanta/playersそのチームのプレーヤーのリストを返送することをお勧めします。これらの違いは、GET以外のHTTPメソッドを使用するAPIを提示する場合にさらに重要になります。
たとえば、チームにプレーヤーを追加したい場合、個々のプレーヤーを追加するたびに/teams/atlanta/playersチームオブジェクト全体をPUTする必要がある場合よりも、プレーヤーオブジェクトをPOSTするだけの方がはるかに簡単です。/teams/atlanta
APIでデータの取得のみが許可されており、特定のクライアントアプリケーション用である場合、すべてのチームデータを1つのオブジェクトに結合して、クライアントがデータに対して追加のリクエストを行う必要をなくすという議論がありますが、次の点に注意してください。柔軟性が低くなります。
アプリケーションは、呼び出してチームのリストを表示したい場合GET /teamsがありますが、これは非常に多くのデータであるため、リスト内の各オブジェクトにすべてのプレーヤー情報を含めることはおそらく望ましくありませんが、プレーヤー情報をGET /teams/atlanta返す場合は一貫性がありません。リストバージョンにも含めないでください。
私は個人的に、私が提案したようにリソースを分割することを好み、クライアントが追加の要求を1つか2つ行う必要があるかもしれないという事実を受け入れます。