2013-04-23 95 views
6

我正在構建事件管理系統。架構如下所述。 API瞭解這些關係並將請求結果中的相關資源鏈接返回。例如,REST - 擴大關係

GET /Events/1 

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

大部分我讀過關於REST和HATEOAS表明,這是「正確」的方式做到這一點但它是非常低效的。例如,如果我想生成參與事件的用戶和團隊的報告,則需要很多請求。這類似於運行多個select查詢,而不是針對數據庫運行單個連接查詢。所以我的問題是,我應該擴大關係並在資源請求中嵌入相關資源嗎?這也會造成問題,因爲上面的請求會返回大量的數據。答案可能是堅持關係鏈接並設置適當的緩存。無論如何,我希望你的意見。

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 

回答

6

在另一個請求的主體中返回資源的完整表示沒有任何問題。正如你所提到的,這可以在詳細的一面。

鑑於服務的某些呼叫者可能只想要返回的URI,但有時您希望減少通過網絡的往返次數,即您希望在一次呼叫中進行所有操作,那麼您搜索的術語是預測

這些是您的資源迎合客戶需求的不同表示。

您可以在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 Cookbook。

+0

謝謝。我無法告訴你我在線閱讀了多少指南/教程,從未遇到過這個術語或概念。 – newb1123 2013-04-24 03:49:05

+0

找不到關於這個術語的任何內容...:S Btw。 Tickets,Teams,Registrations應該是具有單個url屬性而不是字符串的對象。用這種方式處理它們更容易... – inf3rno 2013-09-05 01:58:44

+0

我從RESTFul食​​譜中得到它。它基本上是另一種在不使用正常內容協商或具有數千個表示的情況下對「表示」進行微調的方式。它允許您基本上爲您想要的表示定義規範。 http://www.amazon.co.uk/RESTful-Services-Cookbook-Subbu-Allamaraju/dp/0596801688/ref=sr_1_1?ie=UTF8&qid=1378368152&sr=8-1&keywords=rest+cookbook – James 2013-09-05 08:03:26