あなたのオブジェクトとあなたの応答のためのモデル

Question

私は、私たちが持っているいくつかのレガシーコードを新しいアーキテクチャパラダイムで開発し始めています。さまざまなパラダイムv1とv2を呼びましょう。

v1では、エンティティの情報と属性のすべてを入れ子にしたさまざまなドメイン（ゲームなど）のモデルを用意していました。エンティティの内容と属性の組み合わせを何度も繰り返しました。したがって、エンドポイントにヒットしたときに、ドメインに関連するすべてをネストした応答を得ることができます。たとえば、/ v1 /ゲームでは、ゲーム+選手+チーム+アリーナが表示されます。

v2では、よりリソース指向になるようにしていますので、実際に照会しているリソースを取得できます。たとえば、v2 /ゲーム用のエンドポイントがあり、エンドポイントv2/games/{id}/players。前者ではゲームオブジェクトを取得し、次にゲームオブジェクトを取得します。私は、それはパスで自己ドキュメンタリーだと思う - あなたはあなたが行っている要求を見て取得するつもりだ知っている。

v1では、ドメインの「属性」として何が見えても、すべてが含まれたこの巨大なモデルがありました。実際のモデルには、関連する「属性」のオブジェクトが含まれます。たとえば、ゲームオブジェクトにはプレーヤーオブジェクト配列が含まれます。

実際に同じモデルを使用している場合は、GETに多くの情報（ネストされたオブジェクト）が表示され、POSTでは必要ないフィールドもあります（例：/あなたのポストで選手を送る - 私たちはそれのための別のエンドポイントを持っていた）。 V2モデルで

class Game { 

    public $id; 

    public $datePlayed; 

    public $players = []; 

    public $homeTeam = []; 

    public $awayTeam = []; 
} 

、我々は、データベーステーブルの実際の表現（モデリングのアクティブレコードのアプローチのようなモデルは、永続層に基づいていた）を行います。したがって、ゲームモデルにはプレイヤーは含まれません（プレイヤーは全く異なるオブジェクトなので）。

class Game { 

    public $id; 

    public $datePlayed; 

    public $homeTeamId; 

    public $awayTeamId; 
} 

これまでのところ、私たちは実際に冗長性と不要なデータの多くのネストされたバージョン我々が必要とするリソースを取得していないため、最終的な結果は非常に良いと思います。

しかし、今私は新しい挑戦をしています。実際のデータベース表現ではない詳細情報を返す必要があるエンドポイントがあります。私たちは完璧な世界ではないので、APIを使用する開発者が実際にすべての属性について多くの要求を出すことを望んでいません。関連リソースの基本情報を提供するための解決策が必要です。 。私たちのゲームのエンドポイントに戻っ例えばので

- >私は彼らが私に正確なデータベースオブジェクト

{ 
    "datePlayed": "2016-04-29T17:20:08+00:00", 
    "homeTeamId": 5, 
    "awayTeamId": 15 
} 

しかし、私はとの応答を飾るしたいGETのためにあるペイロードを送りたいん作成します基本データ（オブジェクト全体ではなく、開発者が基本情報を取得し、基本情報ではなく完全な関連リソースを取得する新しい要求のみ）まず

{ 
    "datePlayed": "2016-04-29T17:20:08+00:00", 
    "homeTeam": { 
     "id": 5, 
     "name": "Killer clan" 
    }, 
    "awayTeam": { 
     "id": 15, 
     "name": "Retry team" 
    } 
} 

私は、要求に応じて新しいオブジェクトを作成し、GETメソッドでそれを返すが、POSTを検証し、実際のモデルに要求を置くだろうcontroller->リポジトリにこの責任を委任。しかし、あなたが送信しているものを理解するためにコードを掘り下げなければならないので、これは長期的にはあまりにも保守的ではないようです。

私は長い考えを持ちましたが、コンベンションスタブ（小切手、領収書、切符、その他の書類の一部を切り取って記録として残したもの）で新しいモデルを作成する考えがあります。レスポンスの構造を宣言します。例：/私は、プレースホルダやメタデータはまた、良好な命名規則ですが、要点は同じだと思います。この

class GameStub { 

    public $id; 

    public $datePlayed; 

    public $homeTeam = []; 

    public $awayTeam = []; 
} 

ようGameStubモデルクラスを作成します。

あなたはこのソリューションについてどう思いますか？それは理にかなっていますか？

Answer 1

アプリケーションをapiから切り離すのに適しているため、決定的に意味があります。

APIのリソース=アプリケーションモデル。

私は自分のアプリケーションでは、次の構造を使用します。

モデル - ゲーム（これはあなたのモデルである） のParam - GameParam（あなたは、APIを介して提供したいモデル/ Paramの/リソース） コンバーター - GameConverter（モデルをParamとParamに変換してモデルに変換）

Answer 2

その一部は非常に意味がありますが、私はあなたのスタブのメタファーとそれがどのように問題に関係しているのか理解できませんでした。

GET/games/gameIdは通常、チームIDだけを返します。より多くのチーム情報（チーム名など）を取得するには、ユーザーはGET/teams/teamIdを使用します。ゲームクエリの一部として一部の（ただしすべてではない）チーム情報を送信することで、追加のクエリを回避したいと考えています。

特定のリクエストにどのような追加情報が必要ですか？何らかの要求にコーチの名前が必要な場合はどうなりますか？あなたが何が必要であったのかを推測しようとしているように見え、最終的にすべてをもう一度送ってしまうようです。

Facebookのグラフクエリ言語を見ましたか？ http://graphql.org/

本当に必要な情報を要求することを許可するかどうかの基本的な考え方。 GET/games/gameId？want = teamName、coachName

それから、必要なデータを返す方法はサーバーによって異なります。私はあなたのアプリケーションでgraphqlを使うことを勧めていません。それはほぼ確実に過剰です。

しかし、消費者に必要なものを指定する能力があれば助けになるかもしれません。

是非、コマンドクエリ責任分担（http://martinfowler.com/bliki/CQRS.html）というパターンを活用してください。オブジェクトの作成または更新に関係するものは、それ自身の空間になければなりません。クエリを個別に扱う