我正在开发一种REST API，用于管理公司的汽车，员工可以在这里开车和乘车。乘车具有称为isActive的属性。
他们完成骑行后，需要将isActive属性设置为false。
我的API当前的工作方式是终点（PATCHHTTP请求）的游乐设施是/api/v1/rides。
用户使用JWT令牌发送PATCH请求，并且API从HTTP上下文确定它是哪个用户，找到与该用户关联的个人游乐设施，将isActive属性更新为false，并更新一个short用户输入的string类型的注释。
这可以接受吗？
我发现的每个来源都指出，端点应该看起来像/api/v1/rides/{rideId}，但我不明白为什么在这种情况下为什么有必要这样做，因为这需要在前端进行更多工作。
这可以接受吗？
可能不是
PATCH /api/v1/rides
是更改/api/v1/rides资源的请求；也就是说，您发送GET /api/v1/rides请求时所要求的资源相同。如果您打算修改某些other资源，则要修改的资源应为目标URI。
潜在的问题是：通用HTTP组件认为所有资源都以相同的方式理解请求。这是REST“自描述消息”接口的约束。当您宣传资源支持PATCH时，我的第三方浏览器/蜘蛛/缓存/代理被假定为PATCH对您的资源的含义与对网络上其他所有资源的含义相同。
[当由于您的资源使用的语义与标准语义不同而导致昂贵的错误时，这是您的责任，而不是客户的责任。
PATCH的意思是“将这些更改应用于目标URI标识的资源”。如果要将编辑内容应用于其他资源，则应指定该标识符。
如果您执行的是非标准操作，则可能应使用POST而不是PATCH作为请求中的方法令牌。参见Fielding 2009：
POST在HTTP中有许多有用的用途，包括“此操作不值得标准化的一般用途。”