标准之外的资源上的RESTAPI操作

我正在为一个系统设计一个HTTP API，并计划采用REST风格。该系统的部分功能是跨服务器管理Windows服务。这自然会建议像

GET/servers/：id/services

这样的端点列出服务器上的已知服务，而

GET/servers/：id/services/：name

则详细说明一个服务。除了创建、删除和更新（典型的

POST

、

PUT

、

PATCH

和

DELETE

）之外，还可以停止、启动和重新启动服务。正是这些操作，我不知道该如何处理。我觉得有三个合理的解决办法

提供具体化的命令，即

POST/servers/：id/services/：name/start

，

POST/servers/：id/services/：name/stop

和

POST/servers/：id/services/：name/stop

，

POST/servers/：id/services/：name/restart

将操作状态视为子资源，即

POST/servers/：id/services/：name/operation

启动、

DELETE/servers/：id/services/：name/operation

停止和

POST/servers/：id/services/：name/restart\u required

重新启动。（这最后一项至少与系统的内部行为相匹配，系统不会立即重新启动服务，而是向db发送要重新启动服务的消息。）

将操作状态设置为属性，并使用

PATCH

执行这些操作，即

PATCH/servers/:id/services/:name/{“status”：“started”}

，

PATCH/servers/:id/status/:name/{“status”：“stopped”}

和

PATCH/servers/:id/services/:name/:name{“status”：“restart\u pending”}

---

我不确定哪一个更好。选项1是可以理解的，但它并不完全符合休息的精神。选项2在概念上是一个奇怪的选项，因为它将服务的属性视为单独的（如果是从属的）实体。选项3可能是最干净的，主要的困难是它没有那么明显（需要更仔细地阅读

补丁/服务器/：id/服务/：name

的文档。关于哪种方法的任何想法（包括我错过的任何想法）最干净地公开此功能？

您不应该在资源路径中使用操作。它不是真正的RESTful。根据REST原则，我认为最后一个选项是最好的

事实上，补丁允许对资源状态进行部分更新。您可以在请求负载中自由放置所需内容：

• 例如，字段的新值如下所示：

  PATCH /servers/:id/services/:name/
  Content-Type: application/json
  {"status": "starting"}
  

  如果成功，反应可能是：

  200 OK
  {"status": "started"}
  

• 有一个补丁内容规范，用于更高级的使用。例如，如果您想在资源状态中添加（或删除…）某些内容。您可以在“实现批量更新”一节中查看这篇文章，了解使用示例：

另一个选项是在路径

/servers/:id/services/:name/

上使用方法

POST

，并在内容中提供要执行的操作。例如：

POST /servers/:id/services/:name/
Content-Type: application/json
{"command": "start"}

希望它能帮助你， 蒂埃里