在做一个get时删除一些东西是RESTful吗？

Question

自然答案当然不是，所以为了理解我的目标，请让我解释一下。

我们有一个服务，客户端POST要执行的作业，但它们不会在发布时执行。相反，我们的服务会使用ID进行响应，客户可以使用该ID通过job执行GET。

现在，当作业执行时，它也会被删除，并且该作业不再可用。

根据我对RESTfull架构的理解，我们的实现不符合REST的思想。

所以我想知道的是，如果不是RESTfull，我们应该如何重新设计呢？只是将GET更改为POST（我不相信，因为删除某些内容（工作））同时DELETE似乎也是如此因为执行job

而很奇怪

job我的意思是我们从数据库中提供了大量数据。

Answer 1

  

我们的服务使用客户可用于通过GET执行作业的ID进行响应。

这听起来不像RESTful。客户应该PUT到工作资源，也许将工作状态设置为execute。

PUT /jobs/1234
{
   "status": "execute"
}

200 OK

客户端可以稍后GET作业资源来检查状态。也许以后状态会变为completed。

GET /jobs/1234

200 OK
{
   "id": 1234,
   "status": "completed",
   "quizzle": "smooth"
}

如果在一段时间后系统的某些不同部分删除completed个作业，则作业资源的GET将导致410 Gone。

GET /jobs/1234

410 Gone

Answer 2

RESTfull是一个很好的讨论，其背后的主要概念是使用URI动词和使用HTTP动词的动作来表达资源。我会提出以下三种解决方案，从我认为最优先的解决方案到最少的解决方案。

1. 您可以执行PATCH请求，该请求将更改作业中的字段 - 即等待运行的状态 - 这将在您的后端触发信号并启动作业。后续PATCH请求可以返回400或409响应代码。
2. 您可以对/ jobs /：job_id / execute /执行POST请求，这将开始执行作业。回应可以如上所述。
3. 您可以为GET请求添加副作用 - 这是您的作业执行 - 这会将状态更改为第一次调用时执行。

希望这有帮助，这是一个很好的讨论主题：）

Answer 3

没有。不要通过get执行作业。如果作业已经执行并且有人试图再次发送它，请返回422 Unprocessable Entity，并说明作业已经运行。如果你真的必须，你可以在第二篇文章中删除作业。最好让客户决定是否/何时删除作业。

send up a job:
POST /jobs
{ .. }

execute a job:
POST /executed-jobs
==> { "jobId": 12345 }
<== { "expectedCompletionTime": "<timestamp>" }