任务：我有多个资源需要在一个 HTTP 调用中更新。
要更新的资源类型、字段和值对于所有资源都是相同的。
示例：通过 ID 设置了一组汽车，需要将所有汽车的“状态”更新为“已售出”。
经典 RESTFul 方法：使用请求 URL 之类的 PUT /cars 和 JSON 主体，例如 [{id:1,status:sold},{id:2,status:sold},...]
然而，这似乎是一个矫枉过正：太多次放置状态：已售
寻找一种 RESTful 方式（我的意思是尽可能接近“标准”休息协议的方式）发送状态：所有汽车只售一次以及要更新的汽车 ID 列表。这就是我要做的：
PUT /cars 使用 JSON {ids=[1,2,...],status:sold}但我不确定这是否是真正的 RESTful 方法。
有任何想法吗？
还有一个额外的好处：我希望能够通过简单地设置一个带有如下参数的 URL 来避免少量汽车的 JSON：
PUT /cars?ids=1,2,3&status=sold
这是否足够 RESTful？
一个更简单的方法就是：
{sold:[1,2,...]}
对于更大或更小数量的请求，无需使用多种方法 - 这会浪费开发时间，并且对性能或带宽没有显着影响。
就它是 RESTful 而言，只要它易于被接收者破译并包含您需要的所有信息，那么它就没有问题。
据我了解，使用 put 不足以编写资源的单个属性。一种想法是简单地将属性公开为资源本身：
因此：PUT /car/carId/status 正文内容为“已售出”。
更新不止一辆汽车应该会导致多次放置，因为一个请求应该只针对一个资源。
另一个想法是公开某个协议，您可以在其中构建“批处理”资源。
POST /daily-deals-report/ 正文内容 {"sold" : [1, 2, 3, 4, 5]}
然后系统可以简单地确认正在进行的交易并更新汽车状态本身。通过这种方式，您可以创建一个全新的观点并启用比您实际预期的更像 REST 的 api。
此外，您应该考虑公开一个资源，列出所有可用并因此可以出售的汽车（因此没有出售，不需要维修或不出租）。
GET /cars/pricelist?city=* -> 准备出售的所有汽车的列表，包括汽车 ID 和价格。
这样一来，汽车就没有关于谁拥有汽车的状态。资源通常独立于其所有者（所有者是聚合汽车而不是它的组合）。
每当您难以将操作映射到资源时，您的模型往往会因面向对象的思维而存在缺陷。对于资源，许多关系（父属性）和状态属性往往会错位，因为设计资源比思考服务更抽象。
如果您需要操作许多类似的对象，您需要识别触发这些更改的业务流程，并通过描述其输入的单个资源公开该流程（就像每日交易报告一样）。