Question

我想知道如何为流程方法设计RESTful Web服务。例如，我想为给定的员工ID为ProcessPayroll创建一个REST Api。由于ProcessPayroll是一项耗时的工作，我不需要方法调用的任何响应，只是想异步调用ProcessPayroll方法并返回。我不能在URL中使用ProcessPayroll，因为它不是资源而且不是动词。所以我想，我可以采用以下方法

请求1

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

体

{ “员工”：“123” }

请求2

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

上述哪种方法是正确的？是否有任何Restful API设计指南可以为流程方法和函数提供Restful服务？

Answer 1

上述哪种方法是正确的？

在这两者中，POST最接近。

使用GET / mumble的问题是GET方法的规范将其用于限制为“安全”的操作;也就是说他们不会以任何方式改变资源。换句话说，GET承诺，用户代理和沿途的缓存可以预先获取资源，以防万一需要。

是否有任何Restful API设计指南可以为流程方法和函数提供Restful服务？

吉姆韦伯有一堆文章和谈话讨论这种事情。从How to GET a cup of coffee开始。

但粗略的情节是你的REST api充当流程和消费者之间的集成组件。该协议被实现为对一个或多个资源的操纵。

所以你有一些已知的书签告诉你如何提交工资单请求（想想网页表单），当你提交该请求时（通常是POST，有时是PUT，细节不是立即重要的），作为一方处理它的资源effect（1）从消息中的数据启动ProcessPayroll实例，（2）将该实例映射到其命名空间中的新资源，（3）将您重定向到跟踪工资单实例的资源。

在简单的网络API中，您只需不断刷新此新资源的副本即可获取更新。在REST api中，该资源将返回描述可用操作的资源的超媒体表示。

正如Webber所说，HTTP是一种文档传输应用程序。您的web api处理文档请求，并且该处理的副作用与您的域应用程序协议交互。换句话说，很多资源只是消息......

Answer 2

我们在项目中提出了类似的解决方案，所以如果我的意见不对，请不要责怪 - 我只想分享我们的经验。

资源本身有什么问题 - 我建议像

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

由于作业应该在后台运行，api调用应该返回Accepted (202) http代码。这告诉用户操作将花费很多时间。但是，您应该返回payrollRequestId唯一标识符（例如Guid）以允许用户稍后通过调用以获取发布的资源：

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

希望这有帮助

Answer 3

您决定发布并获得API工作的基础 -

如果您的Rest API在行DB中创建任何新内容（表示数据库中的新资源），那么您必须进行POST。在您的情况下，如果您的工资核算流程方法创建任何资源，那么您必须选择POST
如果您的Rest API同时执行这两项操作，请创建并更新资源。意味着，如果您的工资核算方法处理数据并更新数据并创建新数据，则转到PUT
如果您的Rest API只读取数据，请转到GET。但是我想你的问题是你的工资单方法没有发送任何数据。所以GET不适合你的情况。

我认为你的工资单方法正在做这两件事。

处理数据，意味着更新数据和
创建新数据，表示在DB

注意 - 还有一件事，PUT是幂等的，POST则不是。关注链接PUT vs POST in REST

所以，你必须采用PUT方法。

为调用流程方法设计RESTful API

3 个答案: