我應該使用哪個資源來保留我的API RESTFul？

我正在構建一個API以允許API的客戶端發送通知來提醒用戶更新訂單狀態。到目前爲止，有兩個通知：我應該使用哪個資源來保留我的API RESTFul？

當用戶沒有標記接收到的訂單;
當用戶沒有標記爲完成的順序。

我想要構建這個API來簡化擴展到與訂單相關的其他通知，但爲此API的客戶端保留一個簡單的URI。如何定義我的資源以保持我的API RESTFul？

我在想，我這些結構中的一個：

選項1：

POST: /api/ordernotification/receive/{id} 
POST: /api/ordernotification/complete/{id}

選項2（從資源忽略狀態併發布它來代替）：

POST: /api/ordernotification/?id={id}&statusID={statusID}

編輯

方案2.1（保持關節URI，通過@Jazimov的建議）：

POST: /api/ordernotification/{statusID}/{id}.

哪種選擇更合適？有一個選項比另一個有什麼優勢？或者有沒有其他的選擇我沒有想到？

來源

2015-12-16 Bruno Pessanha

您可以使用：/ api/ordernotification/{statusID}/{id}。這是RESTful，因爲你正在使用一個明確的URI，很明顯你正在使用ordernotification函數 - 讓路由從那裏開始。如果您認爲合適，您還可以靈活地添加狀態。 – Jazimov

也許選項3：'PATCH/api/order/{id}'帶'{status：「收到」}「。（[參考]（http://restcookbook.com/HTTP%20Methods/patch/）） – Kenney

@Kenney我認爲PATCH將是有用的，如果我想更新訂單的狀態。在我的例子中，我只想發送一個通知告訴用戶這樣做。資源「訂單」將保持不變。 –

我會的東西去沿着這些線路

POST /api/order/1234/notifications/not-received 
POST /api/order/1234/notifications/not-completed

可以在以後通過

GET /api/order/1234/notifications/not-received 
GET /api/order/1234/notifications/not-completed

或者

GET /api/order/1234/notification/8899

有一個關於如何語義豐富的一個URI沒有真正限制訪問可以，所以你不妨利用這一點，並明確表示。

來源

2015-12-16 15:26:34 guillaume31

我認爲，要更新已插入記錄的狀態，您的端點應該是PUT而不是POST。

您可以使用

PUT: /api/ordernotification/:id/status/

與客戶JSON數據

{ 
    "status": "your_status" 
}

根據請求數據，終端應更新記錄。

來源

2015-12-16 14:04:58

我不想更新訂單狀態。此API將通知負責執行該操作的用戶。所以在這種情況下，資源將是訂單通知，而不是訂單本身。 –

好的，那麼我認爲你的第二個選擇更好。 –

如果我理解正確，您有兩種類型的ordernotifications：通知receive的通知和通知complete的通知。如果這些是兩個獨立的數據模型，那麼我認爲將它們嵌套是一個好主意（即一個名爲ReceiveOrderNotification和CompleteOrderNotification的表）。如果是這種情況，那麼您可能希望完全暴露兩個不同的端點，如POST /api/receiveordernotification和POST /api/completeordernotification。

但我不認爲這是你能做的最好的事情，因爲那裏有很多重疊的相似之處，可能在訂單通知之間。現在，選擇2更像是一個GET，由於您使用的查詢參數，那麼你的第一個選項，讓我們崩潰他們變成這樣：

POST: /api/ordernotification/

，然後通過它的一些JSON數據來創建通知

{ 
    "orderId": "orderId", 
    "userId": "userId", 
    "prompt": "not marked received/not marked done" 
}

我也刪除了/{id}，因爲當你創建一個全新的東西時，通常你還沒有創建id。即使客戶端正在創建一個id並將其發送到API，將它保持打開狀態也是一種很好的做法，因此您的API可以以自己的方式處理創建新的獨特資源。

這是RESTful是因爲POST創建了具有某些數據點的資源ordernotification。你的第一個選項本身就是一個資源，但在後臺的任何數據模型中可能都沒有。爲了儘可能保持RESTful，您的API端點應該代表數據庫域（表，集合等）。然後，讓您的控制器根據請求中發送的數據選擇使用哪些服務方法。否則，REST端點將提前公開所有邏輯，併成爲一大串不可維護的端點。

來源

2015-12-16 14:29:29

我在指定請求中的狀態時看到的唯一問題是，API的客戶端需要知道要發送的狀態，所以當他們可能只想發送1的通知時，我必須公開我的OrderStatus API狀態，說完成。恕我直言，POST/api/completeordernotification會更簡單和更有意義。 –

我應該使用哪個資源來保留我的API RESTFul？

回答

相關問題