面向任務的用戶界面和Rest應用程序服務器API

我正在設計一個系統，其中將使用面向任務的UI和CRUD UI的混合構造用戶界面。這樣我們就能夠爲不同的用戶角色提供最佳的用戶體驗。面向任務的用戶界面和Rest應用程序服務器API

客戶端應用程序使用REST/JSON與應用服務器進行通信。

對於CRUD部分REST API部分主要是直foreward。但是在我們的應用程序中爲面向任務的動作設計API則有點困難。

一個如何去設計一個REST API，使兩種不同的行爲區別開來的，這兩個其實只是更新數據的資源？

作爲一個例子 - 用戶可以由於以下原因改變一個人的地址：

該地址包含一個故障，例如街道的名稱拼寫爲錯誤。
的人已移動到不同的地址

這兩個原因導致同一端的情況;數據已經改變。但是在REST API中，應該有所不同，以便能夠做出不同的反應。

來源

2011-08-22 RogierBessem

如果您需要有不同的「更新」的方法，那麼我會簡單地包括東西的名稱描述（例如：/Address/UpdateStreetName）。你可以包含一個「/ Update」方法，但是可以包含更具體的名稱，這些名稱可能會顯得有些模糊。

此外，API是以數據還是潛在用戶場景爲中心的？就我個人而言，我會根據數據構建我的API - 但要確保它覆蓋了所有可能的場景。例如，單獨更新街道名稱可能是有意義的（因爲它可能是拼寫錯誤的），但這是否意味着您希望單獨爲每個其他字段提供更新功能？也許，也許不是。可以肯定的 - 一個好的API將允許用戶有效地工作並覆蓋所有/大多數場景（％80>），而不會產生不必要的麻煩，但通過採用以數據爲中心的方法作爲粗略指導，您將成爲不必要地重複的可能性較小。例如，更改地址的原因有很多（在設計時並非所有人都知道），移動到另一個地址只有一個 - 但總體影響會相同（因爲相同的數據正在更改）。

來源

2011-08-23 02:40:07

應用程序的很大一部分是基於CRUD操作的，所以選擇一個以數據爲中心的REST風格的API似乎是我自然而然的選擇。但是與RPC樣式的API相比，這也有一些缺點。舉個例子：/ Address和/ Address/UpdateStreetName都以同一個資源爲目標，但現在使用不同的URI。這不僅僅是以不同的格式進行RPC風格的調用嗎？整體影響是一樣的;地址獲得更新。但是當這個人移動時，我們可能想要給這個人一張明信片到我們不想這樣做的新地址，當我們修正一個錯字時。 – RogierBessem

對我/地址/更新和/地址/ UpdateStreetName是不同的：一個意味着整個地址可以編輯，另一個更精確（但仍然限制爲地址）。對於更具體的情況，您可以採取基於方案的方法，可能是這樣的：/ ChangeOfAddress作爲地址更改可能不僅影響地址;所以你可以使用它作爲其他呼叫的外觀，如/ PhoneNumber/Update（但我可能會偏離這裏的路徑）。 –

我一直工作在一個小工具，它允許您張貼CQRS命令REST風格的URL。 CQRS非常適合面向任務的用戶界面。但是對於一些項目，在管理場景中您可能需要管理整個對象（例如ManagingAddress）。不要忘記，通過更改所有包含管理UI的屬性，您可能會無意中丟失一些由更細粒度命令捕獲的邏輯 - 在您的案例ChangingAddress中）。

在這樣很明顯，要執行兩個獨立的命令的情況下（其中一個是比另一個更只是粒狀的）。無論您將它們表示爲兩個單獨的URL都取決於您，提醒您任何addtional對象可能需要類似的CRUD界面和REST URL。但無論哪種情況，我只是將更細粒度的命令烘焙到我的更復雜的命令中（所以在更廣泛的所有命令中都會提到粒度細節）。

來源

2012-02-28 14:03:37 baseman

通常REST資源將是一個名詞。但是，將資源作爲流程或流程步驟也是合理的。因此，對於你給出的例子，我可以這樣做：

在地址更正筆誤：

PUT /資源/客戶/ 123 /地址

客戶搬家，執行更改地址：

POST /資源/客戶/ 123/changeOfAddress

在後一種情況下，HTTP主體大概包含附加信息，例如「有效日期」。此外，從上述POST返回的內容位置標題可能會包含顯示舊地址，新地址和轉換髮生時間的資源的URI。

因此，changeOfAddress在名義上是一個「過程」，但實際上它本身就是一個名詞;從建模POV來看，它是一流的公民。

來源

2015-11-13 01:31:34

面向任務的用戶界面和Rest應用程序服務器API

回答

相關問題