我知道 REST 端点应该是名词而不是动词，但有时允许有细微的偏差吗？
想象一个应该发布产品的端点（让它在网页上可见，可能会添加一些东西到队列中）。
我可以想出两种方法来解决这个问题。
1) PUT api/products/1/publish - 我喜欢它，因为它是明确的，避免了后端的复杂性并且它自己记录了它。
2) PATCH/PUT/PATCH api/products/1
{
"color": "green",
//some properties removed for brevity
"ispublished" : true
}
第二种方法需要后端服务跟踪帖子正文上的 isPublished 字段，当该字段变为 true 时，开始发布过程。这感觉有点复杂，需要更多维护。
所以我的问题是，从 REST 的角度来看，使用第一种方法可以吗？有什么大的缺点吗？
【问题讨论】：
标签： rest
技术上没有什么可以阻止您在 URL 中使用动词，遵循 RPC 样式。 在概念上这不是 REST 的设计方式。
REST 代表 Representational State Ttransfer。这种架构风格是resource-oriented 并且独立于协议，但它经常通过 HTTP 协议实现。
在通过 HTTP 协议实现 REST 应用程序时，资源由 URI 标识，对此类资源的操作由 HTTP methods 表示（不需要任何其他动词）。要更改资源的状态，您应该向服务器发送资源新状态的表示。表示可以是 JSON、XML 或任何其他能够表示资源状态的格式。请参阅下面的报价：
REST 组件通过使用表示捕获该资源的当前或预期状态并在组件之间传输该表示来对资源执行操作。表示是一个字节序列，加上描述这些字节的表示元数据。其他常用但不太精确的表示名称包括：文档、文件和 HTTP 消息实体、实例或变体。
[...] 给定的表示可以指示请求资源的当前状态、请求资源的期望状态或其他资源的值 [...]
按照这种方法，product 资源可以有一个status 子资源。根据您的需要，status 可以有不同的值，例如draft、published、inactive...
然后使用PUT 将status 子资源的状态替换为请求负载中发送的JSON：
PUT /api/products/1/status HTTP/1.1
Host: example.org
Content-Type: application/json
{
"value" : "published"
}
【讨论】：