Multiple resources can be requested in a GET with filter parameter. Would it be inappropriate to support DELETE on a filtered collection in order to support deleting multiple resources in the same collection concurrently?
The short answer is, the spec doesnât have an opinion on this.
Longer version - From the specification point of view the answer you would get is to create an extension to the standard, and then if widely adopted this could become the standard. The caveat to this being⌠they still havenât finalized the extension mechanism after deprecating the previous one, so how to do it the ârightâ way is somewhat of a open ended question.
From a discussion perspective, I can see the potential benefits to supporting the filter operation on a DELETE to the resource root.
1 Like
I would support this type of extension, but while GETs are fairly low-risk with ambiguity there are certain questions I would like clarified since DELETEs (or even PATCHs or PUTs, for say, marking 11 emails as âreadâ) are generally destructive.
First, it isnât clear to me how to handle a GET /comments?filter[post]=1,2 where the post with id 1 has been deleted or is not available to the individual requesting it (either unauthorized or forbidden). Should the whole GET result in a 400 level error? Should the request return only what it is able to and silently ignore the rest? Should the response do something more complex like assign 200s in the response body for the requested resources that are available and assign 400 level to those that are not?
It seems like a hairy issue. Generally speaking I default to 400-ing the entire requests, but some cases that isnât pragmatic.
Now with a GET it isnât as dangerous as a DELETE. For example, say there is an API for an accounting system and in order to support deletion of an expense that was incorrectly invoiced to a client a client issues a DELETE /transactions?filter[expense]=5&filter[invoice]=7 if the client only has permissions to delete the expense / transaction associated with the expense (since they filed it) but not the invoice or the transaction associated with the invoice, then what should happen?
Iâd argue that in with DELETE the only thing that should be considered safe is ignoring the deletion of something that has already been deleted, otherwise the whole request should be rejected.
I just went through a post in here which discusses the concept of a bulk transaction.
Upon further thought and time to contemplate, I think a specification filter strategy for this type of destructive action is probably ill advised. My initial thoughts were to say no, but I was able to see how this would be beneficial, but considering zachaysanâs comments regarding the failure states I canât get behind this as a specification.
I think the appropriate way to accomplish this is a transaction resource which can take 1 or more operations, which contain 0 or more payloads and can fail or succeed on their own or as a transaction.