CODEWITHSUNDEEP
restdesign-patterns
f.ardelian
f.ardelian

Reputation: 6956

What should DELETE /collection do if some items can't be deleted?

I have a collection of items and some of them may or may not be deleted, depending on some preconditions. If a user wants to delete a resource (DELETE /collection/1) and there are external dependencies on that resource, the server will return an error. But what should happen if the user wants to delete the entire collection (DELETE /collection)?

Should all the resources which can be deleted be deleted and the server return a 2xx, or should the server leave everything intact and return a 4xx? Which would be the expected behavior?

Upvotes: 4

Views: 312

Answers (3)

inf3rno
inf3rno

Reputation: 26139

I think the proper result is 204 no content by success and 409 conflict by failure because of the dependencies (as the others pointed out). I support atomicity as well.

I think you are thinking about REST as SOAP/RPC, which it is clearly not. Your REST service MUST fulfill the uniform interface constraint, which includes the HATEOAS interface constraint, so you MUST send hyperlinks to the client.

  1. If we are talking about a simple link, like DELETE /collection, then you must send the link to the client, only if the resource state transition it represents, is available from the current resource state. So if you cannot delete the collection because of the dependencies, then you don't send a link about this transition, because it is not possible.

  2. If it is a templated link, then you have to attach the "removable" property to the items, and set the checkboxes to disabled if it is false.

This way conflict happens only when the client got the link from a representation of a previous (stale) resource state, and in that case you must update the client state by querying the server again with GET.

  1. Another possible solution (ofc. in combination with the previous ones) to show the link and automatically remove dependencies.
  2. I guess you can use PATCH for bulk updates, which includes bulk removal, so that can be another solution as well.

Upvotes: 1

guillaume31
guillaume31

Reputation: 14064

As a REST API consumer, I'd expect the operation to be atomic and maybe get back a 409 Conflict with details if one of the deletes fails. Plus the DELETE method is theoretically idempotent as @jbarrueta pointed out.

Now if undeletable resources is a normal event in your use case and happens frequently, you may want to stray from the norm a little bit, delete all that can be deleted and return something like a 206 Partial Content (don't know if that's legal for DELETE though) with details about undeleted resources.

However, if you need to manage error cases finely, you might be better off sending separate DELETE commands.

Upvotes: 3

Low Flying Pelican
Low Flying Pelican

Reputation: 6054

I'd say it depends on your domain (although I'd rather use DELETE /collection/all instead of DELETE/collection/),

When you have the situation where you use delete all but some items can't be deleted, it depends on your domain where if you are doing the delete all to free up resources where if not your business process suffers, then it's better to delete what can be deleted and put other into a retry queue makes sense. in that case response should be OK.

Also situations could arise where there could be two operations

  1. Clean Up - only delete unused
  2. Delete All - delete all

In either situation I'd rather use specific method rather than using DELETE on the root URL,

for Clean Up - DELETE /collection/unused

for Delete ALL - DELETE /collection/all

Upvotes: 0

Related Questions