CODEWITHSUNDEEP
restput
jamesplease
jamesplease

Reputation: 12879

RESTful Soft Delete

I'm trying to build a RESTful webapp wherein I utilize GET, POST, PUT, and DELETE. But I had a question about the use of DELETE in this particular app.

A bit of background first:

My webapp manages generic entities that are also managed (and, it happens, always created) in another system. So within my webapp, each entity will be stored in the database with a unique key. But the way we will be accessing them through URLs is with the unique key of the other system.

A simple example will make this clear, I think. Take the URL /entity/1. This will display information for the entity with ID 1 in the other system, and not my own system. In fact, IDs in my system will be completely hidden. There will be no URL scheme for accessing the entity with ID of 1 in my own system.

Alright, so now that we know how my webapp is structured, let's return to deleting those entities.

There will be a way to 'delete' entities in my system, but I put quotes around it because it won't actually be deleting them from the database. Rather, it will flag them with a property that prevents it from appearing when you go to /entity/1.

Because of this, I feel like I should be using PUT ('deleting' in this way will be idempotent), since I am, from the perspective of the data, simply setting a property.

So, the question: does the RESTful approach have fidelity to the data (in which case it is clear that I am PUTing), or the representation of the data in the app (in which case it seems that I am DELETEing)?

Upvotes: 60

Views: 27083

Answers (4)

Istopopoki
Istopopoki

Reputation: 1763

According to the HTTP spec you are performing a DELETE because the URL /entity/1 will not be available anymore after the DELETE. The fact that you soft or hard delete something in your database is not important.

The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the "rm" command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.

If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond the scope of this specification).

Upvotes: 2

Armel Larcier
Armel Larcier

Reputation: 16037

I think there is no definitive answer. I'd rely on whether 1. the soft-delete, recover and destroy actions are an actual feature of your api OR 2. soft-delete is merely a "paranoid" database engineering pattern.

  1. The "soft" deletion is transparent for the api client, in which case using the DELETE verb seems like the way to go

    Everything is as if the item was to be removed once and for all, but engineers want to keep it somewhere in the database

  2. Api clients have the ability to recover or destroy the soft deleted resource, in which case soft deletion and recovery can use POST on a different action url like /resource/:id/softdelete and the destroy action would be the one using DELETE.

    Another way to go may be to use DELETE with no query parameter to soft delete, and add ?destroy=true to actually destroy. But this approach seems less explicit and more prone to errors.

Upvotes: 9

user12489349
user12489349

Reputation:

The DELETE method has very specific semantics in HTTP, which must not be overloaded or stretched by a REST API’s design. Specifically, an API should not distort the intended meaning of DELETE by mapping it to a lesser action that leaves the resource, and its URI, available to clients. For example, if an API wishes to provide a “soft” delete or some other state-changing interaction, it should employ a special controller resource and direct its clients to use POST instead of DELETE to interact.

Source: Rest-API Desgin Rule book by Mark Massé

Suggestion:

POST: /entity/1/your-soft-delete-controller-name

Upvotes: 5

alestanis
alestanis

Reputation: 21863

You should use DELETE.

What you intend to do with your data is called "soft deleting": you set a flag and avoid flagged items from appearing. This is internal to your webapp and the user doesn't have to know that you're soft deleting instead of deleting or whatever you want to do. This is why you should use the DELETE verb.

Upvotes: 97

Related Questions