Mass Resource deletion in REST

Question

I am busy with creating a REST API where you can load company details and then load products for each company, each with their own endpoints

POST /company-details
POST /products

Company details have details in a request body as

companyName
uniqueCode
description
contact
location

Products has information in a request body

uniqueCpyCode
productName
skuNo

Each one will create a record with an auto generated id in a MySQL database. Each to a table for company details and products. Then I also have a delete endpoint to delete products (I also have one for companies)

DELETE /products/{id}

One of the issues I have, I want users to delete all products for a company, but would like to know what is the best practice for mass deletions in my use case.

I am thinking of having an endpoint

DELETE /products/{uniqueCpyCode}

I.e. delete products where cpyCode = request id, but I want to know is that best practice to mass delete resources like that or do I need an endpoint where I need to pass all ids although the number of products can potentially be close to a 1000 products?

Or is it better to only have the one delete endpoint and let the user call it multiple times?

Then another question I have, what if you want to delete the whole company. What is in general the better approach? 1) Call both Delete endpoints.

DELETE /products
DELETE /company

2. the user only call

   DELETE /company

Which internally also call the DELETE /products endpoint.

Answer 1

An important point in REST is that we have a uniform interface; included within that constraint is the idea that the meaning of messages is the same regardless of which resource is specified as the target.

In other words, just as DELETE /products/1 asks that the server remove the association between /products/1 and its current functionality, so too does DELETE /someResourceForBulkDeletes means asks that the server remove the association between /someResourceForBulkDeletes and its current functionality.

What you have here is an impedance mismatch: the message that you are trying to use means one thing, but the implementation does something very different.

That's not necessarily the wrong thing, but if it does cause problems, it's going to be easy for lawyers to blame your implementation for the loss of property (see Fielding, 20020).

HTTP doesn't have any support for requests with multiple target URI; what this means, in effect, is that general purpose components are not going to understand from the request that multiple resources are involved. (For example, web caches are going to be able to apply their cache invalidation policies to the target resource, but not generally to all resources impacted by your implementation.)

In short, HTTP doesn't have a standardized message that means what you want.

Normally, when you want message semantics that don't match a standardized meaning, the correct HTTP method to use is POST. This doesn't necessarily make any of the problems better, beyond the fact that it avoids issues that arise from general purpose components making assumptions based on methods with more tightly constrained semantics.

Part of the problem here may be that you are confusing domain semantics (our contract with this company has been allowed to expire, so we are removing our support) with managing-documents-over-a-domain semantics (HTTP). See Webber 2011.

The fact that your domain semantics happen to have a side effect that makes server resources inaccessible does NOT imply that you should be using DELETE for the corresponding request.

Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect. -- RFC 9110

That said, as an origin server you control your own resource space. If you want to "delete" your resources, then you can -- it may be difficult to communicate to other systems that you have done this, but to some degree that was going to be a problem anyway (Pat's browser won't automatically know that Alex's browser sent a message that triggered a cascade delete, no matter what form the message from Alex takes).