爲調用過程方法設計RESTful API

我想知道如何爲過程方法設計RESTful Web服務。例如，我想爲給定的員工ID爲ProcessPayroll製作一個REST Api。由於ProcessPayroll是耗時的工作，我不需要方法調用的任何響應，只需要異步調用ProcessPayroll方法並返回。我不能在URL中使用ProcessPayroll，因爲它不是一個資源，它不是一個動詞。所以，我認爲，我可以用下面的方法爲調用過程方法設計RESTful API

請求1

http://www.example.com/payroll/v1.0/payroll_processor POST

體

去{ 「員工」：「123」 }

請求2

http://www.example.com/payroll/v1.0/payroll_processor?employee=123 GET

上述哪一種方法是正確的？是否有任何Restful API設計指南爲流程方法和功能提供Restful服務？

來源

2016-08-02 Saran

我們在我的項目中提出了類似的解決方案，所以如果我的意見不對，請不要指責 - 我只是想分享我們的經驗。

什麼涉及資源本身 - 我建議像

http://www.example.com/payroll/v1.0/payrollRequest POST

東西作爲作業應該在後臺運行，API調用應該返回Accepted (202) HTTP代碼。這告訴用戶該操作將花費很多時間。然而，你應該（例如Guid）返回一個payrollRequestId唯一標識符，允許用戶通過調用來獲取發佈資源以後：

http://www.example.com/payroll/v1.0/payrollRequest/{payrollRequestId} GET

希望這有助於

來源

2016-08-02 17:03:16 Artem

了上述方法的一個是正確的一？

其中，POST最接近。

使用GET/mumble的問題在於GET方法的規範將其用於「安全」的操作;也就是說他們不會以任何方式更改資源。換句話說，GET承諾可以預先獲取資源，以便在需要時由用戶代理和緩存中的資源進行預取。

是否有任何Restful API設計準則來爲流程方法和功能製作Restful服務？

吉姆韋伯有一堆討論這類事情的文章和談話。從How to GET a cup of coffee開始。

但粗略的情節是，您的REST API作爲流程和消費者之間的集成組件。協議被實現爲對一個或多個資源的操縱。

因此，您有一些已知的書籤，告訴您如何提交工資單請求（思考Web表單），並且當您提交該請求時（通常是POST，有時是PUT，細節不是非常重要），將它作爲副作用（1）根據消息中的數據啓動ProcessPayroll實例，（2）將該實例映射到其名稱空間中的新資源，以及（3）將您重定向到跟蹤工資實例的資源。

在一個簡單的web api中，您只需刷新此新資源的副本即可獲取更新。在REST API中，該資源將返回描述可用操作的資源的超媒體表示。如Webber所說，HTTP是一種文檔傳輸應用程序。您的web api處理文檔請求，並且作爲該處理的副作用與您的域應用程序協議交互。換句話說，很多資源都只是信息....

來源

2016-08-02 17:32:16 VoiceOfUnreason

你決定後，並獲得API的基礎工作 -

如果您的REST API創建行任何新上DB（意味着數據庫中的新資源），那麼你必須去開機自檢。在你的情況下，如果你的薪資處理方法創建任何資源，那麼你必須選擇開機自檢
如果你的Rest API同時執行，則創建和更新資源。意思是，如果您的工資單處理數據並更新它並創建新數據，那麼請去PUT
如果您的Rest API只是讀取數據，請轉至GET。但正如我想你的問題你的工資單方法不發送任何數據。所以GET不適合你的情況。

因爲我認爲你的薪資方法是做這兩件事。

處理數據，意味着更新數據和
創建新的數據，意味着在數據庫創建新行

注 - 還有一兩件事，在PUT是冪等和POST不是。關聯鏈接PUT vs POST in REST

所以，你必須去PUT方法。

來源

2016-08-02 17:39:13

爲調用過程方法設計RESTful API

回答

相關問題