Hi @Pav. Thanks for raising this. The current REST v2 behavior uses 204 No Content to align with standard HTTP semantics for successful DELETE operations without a response body.
Changing this to 200 OK would be a contract change, since it alters the expected response shape and semantics of the endpoint (even if both are technically valid HTTP responses).
For that reason, this is unlikely to change in v2.
I would’ve expected something returned as well.
The application for which I’m using this API does not, will not, shall not, must not bother with tags in their application or removal. Nevertheless, for the purposes of research, I had to look at the SDK implementation of this operation.
For an SDK/API to return void from a destructive operation is a design flaw, full stop.
/**
* Operation deleteTag
*
* Delete Tag
*
* @param string $tag_id tag_id (required)
* @param string $contentType The value for the Content-Type header. Check self::contentTypes['deleteTag'] to see the possible values for this operation
*
* @throws \Keap\Core\V2\ApiException on non-2xx response or if the response body is not in the expected format
* @throws \InvalidArgumentException
* @return void
*/
public function deleteTag($tag_id, string $contentType = self::contentTypes['deleteTag'][0])
{
$this->deleteTagWithHttpInfo($tag_id, $contentType);
}
@Jeffrey_Chimene - I am avoiding using the official SDK, just building my own one so that i can do additional things when interacting with the API.
Migrating to REST is problematic given that everything is different, and you have to change the code in numerous places. But I am finding things as I am going along.