URI時，包括基於REST的響應信息彙總

比方說，我有一個RESTful API方法返回的數據了一系列的位置：URI時，包括基於REST的響應信息彙總

/地點

[{ 
    location_id: 1, 
    location_name: 'Austin' 
},{ 
    location_id: 2, 
    location_name: 'San Francisco' 
},{ 
    location_id: 3, 
    location_name: 'Seattle' 
}]

現在讓我們說，我想返回的集合每個地點的employee_count：

[{ 
    location_id: 1, 
    location_name: 'Austin', 
    employee_count: 96 
},{ 
    location_id: 2, 
    location_name: 'San Francisco', 
    employee_count: 71 
},{ 
    location_id: 3, 
    location_name: 'Seattle', 
    employee_count: 85 
}]

那麼對於uri最有意義呢？仍然/地點？或者也許/員工/地點？

我擔心的是，計算employee_count與每個/地點的請求可能會導致額外的，浪費的開銷，因爲employee_count只能在5-10％的時間內使用。

來源

2012-07-09 Chad Johnson

你可以把它放在任何一個地方，或兩者兼而有之。你的應用程序的需求應該決定這個選擇。

關於您提出的設計更重要的事實是，您的各個位置對象不包含URI，以便客戶端導航到每個位置以獲取有關它們的更多詳細信息。

相反，您只包含一個ID，這可能是您期望客戶端用於構建位置特定的URI？如果是這樣，你應該強烈考慮爲每個位置的負載添加一個完整的URI（比如「link」或「href」）。如果沒有這種方法，你會將你的客戶與你的URI結構聯繫起來，並使你係統的未來發展變得更加困難。僅供參考，這種方法通常被稱爲HATEOAS（超媒體作爲應用程序狀態引擎）。

來源

2012-07-09 17:55:17

URI時，包括基於REST的響應信息彙總

回答

相關問題