Q: REST DELETE with payload This https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p2-semantics-14#page-20 state that:

Bodies on DELETE requests have no defined semantics. Note that sending
a body on a DELETE request might cause some existing implementations
to reject the request.

This of course make sense.
But we have the scenario that when a customer deletes on of his purchased services that an interaction record needs to be created so CRM is notified can e.g. can try to win back the customer.
When the user delete the service he/she can enter a free format reason which needs to be stored in the interaction.
We just pass this reason text as body payload to the DELETE service call.
Because of some discussion we had I'm wondering if this is semantically right or how others would implement this.
Note: we don't want to send the reason text as query string as in theory this could be very long.

A: As the DELETE you mention has more semantics than specified in HTTP spec (i.e. it affects (creates) another resource), I'd use another resource, e.g. DeleteRequest, to which POST-ing something like:
{
  "resource_href": "http://some/resource/to/delete",
  "reason": {
    "source": "customer request",
    "msg": "I'm really not satisfied with the quality of your service"
  }
}

would has the effect of removing the purchase (or maybe just changing it's state?) and notifying the CRM — and of course creating DeleteRequest resource for e.g. later CRM monitoring.
In more complex systems it is often a better idea to let the object stay (as immutable) and mark it somehow as "invisible" than to delete it permanently, without any traces.
UPDATE: In fact, the current HTTP spec more directly points out that DELETE doesn't have to mean removing the resource and is in line with my feeling that DELETE'ing would be rare. Although the OP quotation of message body semantics is still there.
