在一般的REST架構中，基本概念是資源。 在資源之后，下一步是為這些資源開發一個統一接口，這在HTTP領域通常意味著：

• 創建為POST
• 閱讀就是GET
• 更新為PUT（或部分更新為PATCH）
• 刪除已刪除

在現實世界中，不可避免地某些操作不會很好地映射到資源。 通常這是少數操作，例如重置密碼。 可以將它們建模為

• / password /上的PUT

或作為

• 控制器端點和到/ resetpassword的POST

后者可能被認為比純REST更接近于程序化REST，但是有時客戶和客戶希望您務實。 本文提供了有關何時考慮使用Controller選項的建議。

動作是否映射到CRUD？

現實應用程序中的幾個動作無法很好地映射到CRUD。 例如，貝寶的取消計費協議API是：

POST /v1/payments/billing-agreements/agreement_id/cancel

取消動作很少能很好地映射到資源的CRUD。 它可以解釋為：

• 一些資源被創建（取消記錄）
• 一些資源被更新（某些狀態列可能被設置為取消）
• 或某些資源被刪除（訂單請求被刪除）。

客戶為什么要關心取消的處理方式？ 難道它總是會改變嗎？ 在某些情況下，使用HTTP隧道的API不能很好地映射到CRUD問題。 在取消帳單協議中，這將是：

POST /v1/payments/billing-agreements/agreement_id

與身體：

{"operation":"cancel" }

這被認為是反模式，決不能使用。 而是應使用控制器端點。

資源狀態或工作流程？

在REST體系結構中，客戶端或服務器之間的每個請求通常都會更改資源狀態（寫操作）或應用程序狀態（查詢或讀操作）。 但是，在現實世界中，工作流是不可避免的。 例如，重置密碼流程通常包括：

• 向用戶詢問userId（通常是電子郵件）
• 系統檢查系統上是否存在電子郵件
• 向用戶發送包含重置密碼鏈接的電子郵件
• 確保用戶只有一定時間才能單擊鏈接
• 當用戶單擊鏈接時，他們可能會被問到一系列問題
• 他們將被要求重新輸入新密碼，以確保沒有錯字

當客戶端操作是復雜工作流的一部分時，資源狀態和應用程序狀態更改可能不容易建模。 它們可能不會同步發生，并且可能會根據工作流的建模方式或工作流何時需要添加額外的步驟進行更改。 在這種情況下，請考慮使用控制器端點。

無需PUT的REST

在某些情況下，可以設置參數以避免使用PUT，而可以使用POST到另一個表示意圖的端點。 例如，要更改地址而不是將PUT調用到/ address /，客戶端將調用POST到/ changeaddress并完全避免使用PUT。 這里的想法是使命令/查詢分離更嚴格。 有關更多信息，請參見https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling。 通常，建議使用PUT / PATCH進行更新/部分更新，并且僅在前兩個原因之一適用時才使用控制器端點。

那么，為什么何時使用控制器樣式終結點可能涉及主觀性。 以上至少可以幫助您做出決定。 請記住，在您考慮采用這種方法的情況下，它應該永遠只是少數API。 您在常規的Uniform Interface之外，無法進行獨特的樣式操作，但是您仍然希望使它們對API的客戶來說很直觀。

翻譯自: https://www.javacodegeeks.com/2018/05/rest-using-a-controller-endpoint.html

總結

以上是生活随笔為你收集整理的REST：使用Controller端点？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。