6

イベント管理システムを構築しています。スキーマを以下に説明します。API はこれらの関係を理解し​​、リクエスト結果で関連リソースへのリンクを返します。例えば、

GET /Events/1

    "links": {
    "Venue": "/Venues/1",
    "Tickets": "/Tickets?event_id=1",
    "Teams": "/Teams?event_id=1",
    "Registrations": "/Registrations?event_id=1"
}

REST と HATEOAS について読んだことのほとんどは、これが「正しい」方法であると示唆していますが、非常に非効率的です。たとえば、イベントに参加しているユーザーとチームのレポートを作成したい場合、多くのリクエストが必要です。これは、DB に対して単一の結合クエリを実行する代わりに、複数の選択クエリを実行することに似ています。私の質問は、関係を拡張し、関連するリソースをリソース リクエスト内に埋め込む必要があるかということです。これはまた、上記のリクエストが大量のデータを返すという問題を引き起こします。答えは、関係リンクに固執し、適切なキャッシュをセットアップすることかもしれません. 何はともあれ、ご意見をいただきたいです。

Schema

events
    hasMany registrations
    hasMany tickets
    hasMany teams

team
    belongsTo event

ticket
    belongsTo event
    hasMany registrations

user
    hasMany registrations

registrations
    belongsTo event
    belongsTo ticket
    belongsTo user
    belongsTo team
4

1 に答える 1

6

別のリクエストの本文でリソースの完全な表現を返すことに問題はありません。あなたが述べたように、これは冗長な側にある可能性があります。

サービスの一部の呼び出し元は URI のみが返されることを望んでいるかもしれませんが、ネットワーク全体の往復回数を減らしたい場合、つまり、すべてを 1 回の呼び出しで処理したい場合、検索する用語はProjectionsです。

これらは、クライアントのニーズに合わせたリソースのさまざまな表現です。

これらは URI パラメータで指定できます。GET /Events/1?venueProjection=full,teamProjection=uri

そして、クライアントの要求に従って投影を返します。

"links": {
"Venue": {
    "uri": "/Venues/1",
    "attr1": "value1",
    "attrN": "valueN"
},
"Tickets": "/Tickets?event_id=1",
"Teams": "/Teams?event_id=1",
"Registrations": "/Registrations?event_id=1"
}

注:プロジェクションを含む URI を常に返すようにしてください。これにより、プロジェクションがいっぱいでない場合に、クライアントが後で完全なリソースに簡単にアクセスできるようになります。

Google の「残りの予測」について読むか、RESTful クックブックをチェックすることをお勧めします。

于 2013-04-23T15:30:28.157 に答える