非CRUD API的RESTful設計

Question

我一直在尋找一個教程或網站，該教程或網站介紹了設計api的最佳實踐，該api不僅代表典型的Create-Read-Update-Delete中的資源。

假設我想以RESTful的方式表示在基類庫中找到的典型API（一些表示Singleton模式/ Factory模式等），我可以找到有關大多數教程和有關簡單POST，PUT，GET，DELETE方法的信息。創建，讀取，更新不足夠。

是否有一套標准的准則，以RESTful方式“還原”更復雜的API和/或標准設計模式？

舉個例子，對一個文件實例提供MOVE和COPY操作的最佳方法對我來說還不清楚，而且有很多方法可以實現。

POST http://www.api.com/api/file/<fileidentifier>/COPYTO/<newfileidentifier>

要么

POST http://www.api.com/api/file?directory=<dir>&filename=<filename>
BODY { operation: "copy", newDirectory: "<$newdir>", newFilename: "<$newfilename>"

等等

我應該遵守哪些設計准則？

Answer 1

我希望您將Odata v4添加到其中，然后創建服務，因為我在過去8個月中一直在處理相同的情況。 優點 1.無需進行很多搜索查詢功能。 2.有可用的Odata客戶端，它可以像Wcf一樣基於元數據生成客戶端代碼。 所以這也是一個很大的優勢。 3.不要使用put post get API的基本名稱約定，而應使用函數名稱來描述函數的實際作用。