REST - 関係を拡張する

Question

私はイベント管理システムを構築しています。スキーマについては後述します。 APIはこれらの関係を理解し​​、要求結果の関連リソースへのリンクを返します。例えば、私はRESTについて読んだとHATEOASが、これはそれを行うには「正しい」方法であることを示唆しているものの大部分

GET /Events/1 

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

は、しかし、それは非常に非効率的です。たとえば、イベントに参加しているユーザーやチームのレポートを生成する場合は、多くのリクエストが必要です。これは、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 

Answer 1

別の要求の本文に完全なリソース表現を戻すことは間違いありません。あなたが言及したように、これは冗長な側にあることができます。

サービスの発信者の中には、返されたURIだけが必要な場合がありますが、ネットワーク全体の往復回数を減らしたい場合、つまり、1回の呼び出しですべてを欲しければ、検索する用語は予測。

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

あなたは、例えば、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から "rest projections"を読んだり、RESTful Cookbookをチェックしたりすることをお勧めします。