自定義操作的API RESTful URL路徑

我有一個預算實體...自定義操作的API RESTful URL路徑

在某些時候，應用程序可讓您爲客戶端創建新的預算。在保存預算之前，您可以選擇生成基於您的選擇的總金額的預覽。

這些計算都在服務器完成的，所以我需要暴露適當的終點，但我不知道終點應該是什麼。

我在想[GET] http://example.com/budgets/preview/與一起發送所需要的參數。

這是正確的嗎？這將指向budget類中的preview()方法。

那麼我已經保存的預算怎麼樣？

[GET] http://example.com/budgets/{ID}/preview/？

來源

2017-08-10 Matías Cánepa

請勿在/budgets之後超出URL段以包含ID或「預覽」。相反，使用

[GET] /budgets/{id} 
[POST] /budget-previews 
     > returns a preview given the data in the body 
[GET] /budget-previews/{id} 
     > returns a preview given data on the server

現有預算可以提供預覽鏈接，而新預算可以請求預覽。如果您選擇，您可以在執行POST /budget-previews時單獨保存預覽，然後可能通過預覽POST /budgets?previewId={}（或將預覽ID置於POST的正文中）創建預算。我會避免使用預算ID作爲預覽ID，以防您稍後決定另行保存預覽。

如果有，將是任何其他類型的預覽，可以考慮使用的/previews代替budget-previews。

來源

2017-08-10 19:03:53

記住，其餘的都是關於有在需要的資源，的第一件事情，以確定是哪些資源，並在它們之間有任何關係，這樣一個多表示。

對我來說，這似乎是你有一個預算作爲一種資源和budgetPreview作爲資源的概念，並且希望在以後的日子來獲取其中一方以及能力。

我建議以下的URI'seems

[GET] http://example.com/budgetPreviews/generate

這將生成並在服務器上返回budgetPreview而不存儲它。海事組織在API中看起來並不清楚，創建budgetPreview的路線嵌套在預算之下。我還主張稍微擺脫「所有終結點都必須是名詞」，以支持可以預測的資源或資源的商業行爲。如果有人爭辯說，你可以將generate生成爲「generateRequest」，因爲實際上你將一個文檔傳遞給服務器，並填充了代表你生成budgetPreview的請求的值。我在這裏做的一個假設是服務器構建budgetPreview所需的所有信息都是從GET請求中的客戶端傳遞的。

的一件事警惕的是在這裏，您將需要包括所有的URI您的信息查詢參數，因爲返回的值將根據參數是不同的。在GET主體中傳遞值然後給出主體的語義含義（即根據身體中的值創建不同的資源）將會破壞緩存（如果你做任何事情）。

[GET] http://example.com/budgetPreviews

返回所有現有的存儲budgetPreviews

[PUT] http://example.com/budgetPreviews/ {GUID}

使用看跌期權來這裏創建資源，並允許客戶端來確定的id意味着存儲資源的請求可以在超時的情況下重試並允許冪等性。與此同時，您正在存儲預算預覽，您可以在參數中提供預算的標識並將其鏈接起來。

[GET] http://example.com/budgets/ {GUID}/budgetPreview

[GET] http://example.com/budgetPreviews/ {GUID}

這些是不同的URI識別相同的資源，並且允許在客戶端不同的方式來消耗budgetPreview

一個額外的觀點不是混淆你的底層資源或實現細節，比如調用哪個方法和你面向公衆的API。旨在讓您的公衆面對API儘可能適合客戶，並且您返回的表示重點關注對客戶合約進行建模，而不是將底層資源持久化。另外，智者曾告訴我的另一件事是記住你擁有無限的URI，所以不要害怕創造更多的東西，因爲它會讓你的API清晰明瞭，你的客戶正是他們想要的東西。

來源

2017-08-10 19:26:58 nrjohnstone

自定義操作的API RESTful URL路徑

回答

相關問題