REST風格的API命名資源和控制器設計

Question

只需閱讀一些RESTful API設計最佳實踐即可。我來自ASP.Net Web窗體背景，我一直在調用WebMethods後面的代碼來將數據返回給我的客戶端JavaScript。對我來說，將這些WebMethod移出到一個API似乎邏輯上，所以我們可以開始集中和標準化我們如何回調終端系統。

我理解REST的目的是對資源爲GET，POST，PUT和DELETE分類的操作。這些資源也可以使用名詞而不是動詞。

1） 所以我有兩個方法，返回的數據生成報表。由於客戶端綁定和每個報告的其他特定屬性，我創建了各自的類別細分突發事件和細分分鐘。

[的WebMethod] Top10MinutesBreakdowns

|Machine|Department|Total Minutes|etc.| 

[的WebMethod] Top10IncidentsBreakdowns

|Machine|Department|Total Incidents|etc.| 

如果這些方法來組織：

GET /Breakdowns?report=minutes&type=top10 
GET /Breakdowns?report=incidents&type=top10 

然後在我的故障控制器中檢查參數並調用相應的現有業務層功能來返回數據？

2）報告返回兩個不同的特性（簡單起見：分鐘和事件＃）的＃。我真的應該將這兩種方法分組到同一個控制器嗎？

這是我很困惑，因爲報表使用不同的屬性，但根本目的是擊穿。也許這個問題更適合重新設計我的業務對象本身。我發現我們現有的業務層有很多爲綁定客戶端視圖而創建的類。我確信在嘗試構建此API時會遇到更多這些場景。

Answer 1

這是沒有問題的有兩個調用返回一個不同的資源。只要將報告參數視爲屬性過濾器的一種。如果您未通過報告參數，則只需返回兩個屬性作爲細分資源的一部分即可。

你還可以包括一個字段參數，使返回的屬性更加明確，如：/api/breakdown?fieldset=machine,department,minutes。

如果您有許多具有各種資源屬性的報表，您可能會考慮類似於GraphQL，它允許您顯式指定多個資源的屬性以在單個查詢中返回。

Answer 2

我知道REST的目標是將資源上的操作分類爲GET，POST，PUT和DELETE。這些資源也可以使用名詞而不是動詞。

不是真的 - REST的目標是明確支持網絡規模應用程序所需的約束條件。見Fielding, 2000

這是我很困惑，因爲報告使用不同的屬性，但基礎對象是一個分解。

不要將您的API與您的底層實現/表示混淆。 Top10MinutesBreakdowns和Top10IncidentsBreakdowns 信息資源碰巧使用對同一個基礎對象的引用，這是您當前實現的意外。

換句話說，您的控制器是適配器，支持錯覺只是一個理解HTTP請求消息的文檔存儲。

選擇在相同的控制器或不同的控制器中支持這兩個報告確實取決於這些報告相對於彼此的變化頻率，自定義請求路由到相應控制器的成本等等。

任何您可以正確路由的URI拼寫都可以，但我個人傾向於給這些報告標識符自己。

GET /Top10MinutesBreakdowns 
GET /Top10IncidentsBreakdowns 

然後配置您的路由以將這些請求傳遞到相應的控制器。