问发送命令的RESTful方式

EN

在过去的项目中，我经常遇到这样的情况。因为REST是well...about资源，所以并不总是清楚如何处理本质上是RPC的东西。

解决这一问题的一个简单方法是将其视为rest的官僚部分，请求本身可以是一种资源：

1.“您想在我的服务器上触发命令吗?请先填写此表单I90292并将其发送给我们”：

POST /bureaucracy/command-request 
Content-Type: application/x-www-form-urlencoded
Content-Length: ...

1. “好的，我们看看我们能做些什么。你的案例编号是999。”

201创建(或根据库格尔的评论接受202 ) Location /bureaucracy/command-request/999

• And，然后客户端定期检查

GET /官僚机构/命令请求/999

希望他能得到下面这样的响应

200 OK
<command-request>
  <number>999</number>
  ...
  <result>Success</result>
</command-request>

当然，如果官僚服务有很好的客户关怀，它会让客户在完成工作后打电话给他，如果他想的话：

“您想在我们的服务器上触发命令吗?请填写此表单并将其发送给我们。请注意，您可以加入您的联系信息，这样我们就可以在完成时通知您”

POST /bureaucracy/command-request?callback=client.com/bureaucracy/inbox 

或作为自定义http标头X-Callback: http://client.com/bureaucracy/inbox

我建议这样做：

• 创建一个你可以获得的资源，如果这个命令有副作用，它将告诉你客户端如何使用POST发送命令，类似于一个超文本标记语言表单。
• POST到资源来触发命令，并将URI返回到你在POST请求执行期间创建的新资源(例如http://server.example/results/00001)，可能带有204 (无内容)状态和位置标头或重定向(取决于哪个客户端可以使用understand).
• Let客户端使用GET检查该资源的结果)。您还可以返回此资源(或类似内容)的表示形式，作为POST之前返回的实体。

结果资源的生命周期由您决定。如果你不需要长时间存储结果，它可能是短暂的。例如，URI可以从UUID构造。

在您的情况下，为什么不将cache作为资源呢？

DELETE /cache

当你想冲水的时候。

POST /cache

当你想要创建一个新的。

或者将前两个合并为以下内容：

DELETE /cache?autorecreate=true