I would not return a simply success status in the response, the http error code only signals success or error. I'd only include use the response itself to add detailed error information such as application specific error codes or error messages.

For PUT, PATCH and POST requests you typically return the state return the state of the resource after the request has been applied, not an empty response.

For POST requests that represent an action instead of simply creating a resource (not very RESTful, but still useful in practice), which doesn't have useful data to return, I'd return a response consisting of an empty json object, i.e. {}. That way the client gets a valid response and adding some information later on is unlikely to break it.

For DELETE requests returning 204 and an empty body is pretty common, which makes sense since the resource doesn't exist afterwards.

I would not return simply a success status in the response, the HTTP error code only signals success or error. I'd only include the response itself to add detailed error information such as application-specific error codes or error messages.

For PUT, PATCH and POST requests you typically return the state of the resource after the request has been applied, not an empty response.

For POST requests that represent an action instead of simply creating a resource (not very RESTful, but still useful in practice), which doesn't have useful data to return, I'd return a response consisting of an empty JSON object, i.e. {}. That way the client gets a valid response and adding some information later on is unlikely to break it.

For DELETE requests returning 204 and an empty body is pretty common, which makes sense since the resource doesn't exist afterwards.