我对 REST 足够熟悉,可以认识到使用 POST 来实现 DELETE 是对 REST 合规性的偏离。我无法确定这是一条好规则的确切原因。
我怀疑它可能与 API 无关工具的可行性有关(例如,一个开发工具,它根据关于动词定义的给定对实现的状态做出假设,而无需配置以了解哪些特定的 API 方法做)或在部分成功删除的情况下无法返回细粒度错误,但这些只是猜测,并不是这个问题的真正核心。
Swanliu 的回答是指使用表示分组构造的 URL 作为删除的目标,但给出的示例“/users/expired”暗示了一个固定的(可能是系统定义的)分组。任意集合的更面向用户的情况仍然需要在某些时候进行枚举才能实现。
为一个大小为 N 的组发出 N 个 DELETE 没有吸引力,因为复合延迟和缺乏原子性,但 REST DELETE 可能只针对单个资源。
我认为 Swanliu 的回应暗示的最佳实践可能是定义一个 POST 操作,该操作能够创建一个资源,该资源成为要删除的对象的新包含父级。POST 可以返回一个主体,因此相关系统可以为这个非域分组资源创建一个唯一标识符并将其返回给客户端,客户端可以转身并发出第二个请求以删除它。POST 创建的资源是短暂的,但却是有目的的——它的消亡级联到作为批量删除操作所需目标的域对象。
> POST /users/bulktarget/create
> uid=3474&uid=8424&uid=2715&uid=1842&uid=90210&uid=227&uid=66&uid=54&uid=8
> ...
< ...
< 200 OK
< ae8f2b00e
> DELETE /users/bulktarget/ae8f2b00e
> ...
< ...
< 200 OK
诚然,两个网络交换不如一个,但考虑到较小的批量删除是两个对象,并且需要两个 DELETE 操作才能解决,这似乎是一个公平的权衡 - 想想它就像你得到每一个对象超出第二个免费。