如何通过FSM状态更改最好地扩展REST？
没有人知道状态改变是否正确，所以最明智的事情可能是假设状态改变不是，并且通常使用POST，好吗？
对我和我的发现而言，POST比PUT或PATCH更有意义。
POST /coffeemachines/{id}/start
或更冗长？
POST /coffeemachines/{id}/state/start
尽管 start 看起来像一个动词（破坏REST实践），但我认为不是：
我想我不是这里的第一个登月的人，感谢任何参考或想法。
答案 0 :(得分：1)
您可以使用HTTP PATCH发送仅包含新状态的部分更新请求。
PATCH /coffeemachines/{id}
{
status: "active"
}
根据Wikipedia：
PATCH方法是HTTP协议支持的请求方法，用于对现有资源进行部分更改。 PATCH方法提供了一个包含更改列表的实体，该更改列表将应用于使用HTTP URI请求的资源。更改列表以PATCH文档的形式提供。
使用连字符分隔路径中的单词也更容易理解。例如：
PATCH /coffee-machines/{id}
{
status: "active"
}
答案 1 :(得分：1)
用于状态更改的REST动词-我们可以同意POST吗？
REST的参考实现是万维网，尽管HTML（主要的媒体类型）仅指定了对GET和POST的支持，但它还是取得了灾难性的成功。
使用POST进行不安全操作很好。
尽管开始看起来像一个动词（破坏REST实践）
否-REST不在乎URI的拼写。这就是重点的一部分：服务器可以随时更改链接中的URI，因为客户端只需跟随链接即可。
也就是说，您建议的标识符存在问题，您可能需要考虑
/coffeemachines/{id}
/coffeemachines/{id}/start
就REST而言，它们是不同的资源。这意味着当您/coffeemachines/{id}对POST的请求时，/coffeemachines/{id}/start的本地缓存副本不是invalidated。
如果您想利用现有的域不可知组件中已内置的缓存支持，那么您希望POST的目标与GET的目标相匹配： /coffeemachines/{id}
/coffeemachines/{id}/start不是POST的目标，而是表单资源的标识符，该表单资源向/coffeemachines/{id}提交了起始消息。同样，/coffeemachines/{id}/stop将标识提交停止消息的表单资源。
当允许转换时，咖啡机的表示形式将包括这些表格的链接；例如，当咖啡机关闭时，GET返回的咖啡机的表示形式将包括指向起始表单的链接，而不包含指向终止表单的链接。
/coffeemachines/{id}/start和/coffeemachines/{id}/stop是与/coffeemachines/{id}不同的资源，因此可能具有自己的缓存策略。
当然，不需要将表单作为单独的资源-如果表单是/coffeemachines/{id}资源本身表示的一部分，则该机制也将起作用。 / p>
我能否请您详细说明POST与PATCH
我发现这个observation by Roy Fielding帮助了我：
HTTP不会尝试要求GET的结果是安全的。它的作用是要求操作的语义是安全的，因此，如果发生任何导致财产损失的事情，这是实现的错，而不是接口或该接口的用户
PATCH的语义比POST更严格；这意味着客户（和通用组件）可以对发生的情况做出更强的假设。
因此在以下示例中：
PATCH /foo HTTP/1.1
Content-Type: application/json-patch+json
POST /foo HTTP/1.1
Content-Type: application/json-patch+json
服务器可以完全相同的方式处理这些消息。认识到PATCH方法的客户端将认识到，服务器上的不安全更改应该是全部或全部（“服务器必须以原子方式应用整个更改集...”），并且可以随意使用它们，但是使用POST时，缺少了附加约束，因此无法假定。
PATCH规范说明：
与POST进行比较甚至更加困难，因为POST的使用方式千差万别，并且如果服务器选择，则可以包含类似PUT和PATCH的操作。如果操作无法以可预测的方式修改Request-URI标识的资源，则应考虑使用POST而不是PATCH或PUT。