Question

我正在为系统设计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_required重启。（这最后至少与系统的内部行为相匹配 - 它不会立即重新启动服务，而是发布到要重新启动服务的数据库。）
将运营状态设为属性，并使用PATCH执行这些操作，即PATCH /servers/:id/services/:name/ {"status": "started"}，PATCH /servers/:id/services/:name/ {"status": "stopped"}和PATCH /servers/:id/services/:name {"status": "restart_pending"}。

我不确定哪个更好。选项1是可以理解的，但它并不完全符合REST的精神。选项2在概念上是一个奇怪的，因为它将服务的属性视为单独的（如果是从属的）实体。选项3可能是最干净的，主要的困难是它不那么明显（需要更仔细地阅读PATCH /servers/:id/services/:name的文档。任何关于哪种方法（包括我错过的）的想法最干净地揭示了这个功能？

Answer 1

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

实际上，patch允许部分更新资源状态。您可以自由地将所需内容放入请求有效负载中：

例如，仅使用类似的字段的新值：

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

如果成功则可以回复：

200 OK
{"status": "started"}

为了更高级的用法，有一个名为JSON Patch的PATCH内容规范。例如，如果要在资源状态中添加（或删除...）某些内容。您可以在“＃34;实施批量更新＆＃34;”部分中查看此帖子。使用样本：http://restlet.com/blog/2015/05/18/implementing-bulk-updates-within-restful-services/。

另一种选择是在路径POST上使用方法/servers/:id/services/:name/，并在内容中提供要执行的操作。例如：

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

希望它能帮到你，亨利

REST Api对标准之外的资源的操作

1 个答案: