域内机器启停等操作的REST API设计：两种PUT方案哪一种更RESTful？

哪个方案更符合RESTful规范 #

方案2的设计更符合RESTful设计规范，核心原因如下：

• REST架构的核心是资源唯一标识，每个URL应该对应一个明确的资源：/domains/x/machines/y 精准指向域x下名称为y的单台机器资源，符合资源定位的设计原则；而/domains/x/machines 对应的是域x下的机器集合资源，用PUT请求集合资源来修改单个资源属性，违背了HTTP方法的语义约定。
• PUT方法的原生语义是「向指定资源位置上传其最新的完整状态」，方案2的请求语义非常清晰：将/domains/x/machines/y这个资源的state属性更新为running，可读性和可维护性都远高于方案1。

第二种方案更新state属性是否存在问题 #

不存在任何问题。
state本身就是机器资源的固有属性，直接通过PUT单个机器资源的路径更新其属性完全符合REST的设计逻辑，甚至可以根据实际需求做拓展：如果只需要更新state这一个字段，不需要传递机器的其他完整属性，可以将PUT改为PATCH请求，语义会更加精准。

方案1的不合理之处 #

• 方法语义不匹配：PUT请求集合资源通常用于全量覆盖整个集合，用来操作单个资源会让接口语义混淆。
• 容错性更低：需要在请求体中额外传递machine_name参数，一旦参数和实际操作目标不匹配，会增加异常排查的成本。
• 权限控制实现更复杂：需要从请求体中解析机器名称才能校验操作权限，方案2直接从URL路径中即可提取目标资源标识，实现成本更低。

内容的提问来源于stack exchange，提问作者ca9163d9