我们都知道,通过REST删除单个项的“标准”方法是向URI
据我了解,这个问题的“典型”解决方案是采用“两步”方法。首先,客户端POST列表项ID,并返回一个URI(例如
现在,我认为这个方法也可以正常工作,但对我来说,它是一个糟糕的解决方案。首先,你强迫客户端进行两次请求以适应服务器。其次,“我认为DELETE应该删除一个Item?”,调用此URI上的DELETE应该有效地取消事务(尽管不是真正的事务),那么我们该如何取消它呢?如果有某种形式的“执行”操作,那最好了,但我不能太过分。它还强迫服务器考虑“JSON看起来更像是修改这些项的请求,但请求是DELETE...所以我想我会将它们删除”。这种方法也开始在客户端/服务器上强加某种状态,虽然不是真正的状态,但确实如此。
我认为,更好的解决方案是简单地调用
example.com/Items/666
发送一个DELETE请求。接下来让我们来看看如何批量删除。由于我们不需要原子删除(或真正的事务,即全部或无),我们可以告诉客户端“很遗憾,请发送多个请求”,但那样并不好。因此,我们需要一种允许客户端请求同时删除多个'Items'的方法。据我了解,这个问题的“典型”解决方案是采用“两步”方法。首先,客户端POST列表项ID,并返回一个URI(例如
example.com/Items/Collection/1
)。创建该集合后,他们调用DELETE操作。现在,我认为这个方法也可以正常工作,但对我来说,它是一个糟糕的解决方案。首先,你强迫客户端进行两次请求以适应服务器。其次,“我认为DELETE应该删除一个Item?”,调用此URI上的DELETE应该有效地取消事务(尽管不是真正的事务),那么我们该如何取消它呢?如果有某种形式的“执行”操作,那最好了,但我不能太过分。它还强迫服务器考虑“JSON看起来更像是修改这些项的请求,但请求是DELETE...所以我想我会将它们删除”。这种方法也开始在客户端/服务器上强加某种状态,虽然不是真正的状态,但确实如此。
我认为,更好的解决方案是简单地调用
example.com/Items
(或者可能是example.com/Items/Collection
)上的DELETE,并传递包含您希望删除的ID列表的JSON数据。据我所见,这基本上解决了第一种方法所遇到的所有问题。它更容易作为客户端使用,减少了服务器需要做的工作量,是真正无状态的,更语义化。我希望您能反馈一下这个问题,我是否忽略了REST的某些东西,从而使我解决这个问题的方法变得不现实?如果有比较这两种方法的文章,请提供链接,我会非常感激。尽管这在SO上通常是不被批准的,但我需要能够驳斥只有第一种方法才是真正的RESTful,并证明第二种方法是可行的解决方案。当然,如果我走错了路,请告诉我。