CODEWITHSUNDEEP
restapi
Tehel
Tehel

Reputation: 113

Should a REST API be protective of data behind?

On DELETE queries that will possibly cascade into removing a lot of data, should my REST API blindly proceed or warn about it and ask for confirmation ?

I'm building an API that abstracts the manipulation of complex data stored in a relational DB. Removing an item that is referenced by other items should logically remove them to, and then cascade.

A simple example (unrelated to the real case) would be a set of three "Tree/Branch/Leaf" tables: Leaf rows have a foreign key to a Branch's id, and Branch rows similarly include a Tree id. The API enables DELETE at any level, but if you remove a Tree item, it will internally cascade into removing all the Branchs and Leafs that directly or indirectly reference it.

So on a DELETE query for a Tree, the API could:

I tend to think that the API should stay simple and that foolsafe protection should be in the client, but would appreciate external wisdom.

Upvotes: 1

Views: 121

Answers (1)

Evert
Evert

Reputation: 99667

As usual for questions like these, the answer really is 'it depends'. Personally, if you would go for the route of having to 'confirm' a large deletion, I would instead:

  1. Add a depth or cascading header. Instead of 'do you really want this?' you know ask your developers to make sure they want to do a deep delete. Depth is a standard header but appears in the WebDAV spec. Cascading wouldn't be, so you might prefix it with X- depending on whether you feel that that's a good idea =)
  2. Respond with a 409 if that header was not specified. This is how WebDAV does it and makes a lot of sense here.

However, from my point of view I think I would rather have an 'undelete' option.

Upvotes: 1

Related Questions