Delete request with payload data

Like with HTTP, we don't define payload semantics with the DELETE operation. You could allow a client to provide a request body, but at that point you're stepping outside of the Redfish spec. There is an update about this in RFC9110: datatracker.ietf.org/doc/html/rfc9110#name-delete

> Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

So, while you can do that, it's certainly frowned upon. The semantics of DELETE are to remove the URI specified by the client; you don't need a payload to augment that sort of request.

You can define an action with a side effect that deletes a resource. For example, the ClearLog action on LogService can be thought of as a glorified "delete all" for the members of the log entry collection. You just need to define the action in schema, give clear descriptions for its behaviors, and show the action in the resource in question where you want to perform this type of operation.