REST API標準之外的資源操作

我正在爲系統設計一個HTTP API並計劃採用REST風格。該系統功能的一部分是管理跨服務器的Windows服務。這自然會建議像GET /servers/:id/services這樣的端點列出服務器上的已知服務，並使用GET /servers/:id/services/:name來詳細說明。除了正在創建，刪除和更新（典型的POST，PUT,PATCH和DELETE）之外，還可以停止，啓動和重新啓動服務。這些操作我不確定如何處理。我認爲這是三個合理的解決方案。REST API標準之外的資源操作

提供具體化的命令，即POST /servers/:id/services/:name/start，POST /servers/:id/services/:name/stopPOST /servers/:id/services/:name/stop和，POST /servers/:id/services/:name/restart。
將運行狀態視爲子資源，即啓動POST /servers/:id/services/:name/operation，停止DELETE /servers/:id/services/:name/operation並重新啓動POST /servers/:id/services/:name/restart_required。（這最後至少與系統的內部行爲相匹配 - 它不會立即重新啓動服務，而是發佈到數據庫以重新啓動服務。）
使運行狀態成爲屬性並使用PATCH執行這些操作，即PATCH /servers/:id/services/:name/ {"status": "started"},和PATCH /servers/:id/services/:name {"status": "restart_pending"}。

我不確定哪個更可取。選項1是可理解的，但它不完全符合REST的精神。選項2在概念上很奇怪，因爲它將服務的屬性視爲單獨（如果是從屬）實體。選項3可能是最乾淨的，主要困難在於它不是很明顯（需要更詳細地閱讀PATCH /servers/:id/services/:name的文檔。對於哪種方法（包括我錯過的任何方法）的任何想法都能夠最清楚地展示此功能嗎？

來源

2015-10-16 walpen

你不應該在資源路徑中使用動作，它不是真正的RESTful，我認爲最後一個選擇是最好的選擇，根據REST原則

事實上，patch允許部分更新資源狀態。把你想要的東西放在請求有效載荷中：

例如字段與類似的東西簡單地將新的值：

PATCH /servers/:id/services/:name/ 
Content-Type: application/json 
{"status": "starting"}

和反應可能是，如果成功：

200 OK 
{"status": "started"}

有更高級的用法稱爲JSON Patch的補丁內容的規範。例如，如果您想添加（或刪除，...）某種資源狀態。您可以在「實施批量更新」部分查看此帖，以瞭解使用示例：http://restlet.com/blog/2015/05/18/implementing-bulk-updates-within-restful-services/。

另一種選擇是使用路徑上/servers/:id/services/:name/方法POST和內容操做提供。例如：

POST /servers/:id/services/:name/ 
Content-Type: application/json 
{"command": "start"}

希望它會幫助你，蒂埃裏

來源

2015-10-16 16:45:41

REST API標準之外的資源操作

回答

相關問題