Avoid sending empty JSON body when using destroy_method = "PUT"

[broestls]

I am trying to implement some Terraform-like behavior in a resource exposed by the Infoblox API but not available via the first-class provider. In this case, I want to change an attribute of an object to mark it as reserved, then null those properties when the resource is no longer needed. This is because the object I'm working with persistently exists and can't/shouldn't be deleted.

So I followed the example in terraform-provider-restapi/examples/update_field_with_put_request.tf. I use an external script with a restapi datasource to get the next available object from my API's pool. Then I use the restapi resource to redirect the create action from POST to PUT. The create and change methods work great:

locals {
  tenant_private_extattrs = {
    extattrs = {
      "Tenant ID" = {
        value = "sh_${var.tenant_name}"
      }
    }
  }
}
resource "restapi_object" "tenant_private_vlan" {
  path           = "/${data.external.next_private_vlan.result._ref}?_return_as_object=1"
  object_id      = data.external.next_private_vlan.result._ref
  create_method  = "PUT"
  destroy_method = "PUT"
  data           = jsonencode(local.tenant_private_extattrs)
}

When it comes time to destroy though, the upstream API complains because the restapi provider tries to send an empty json body and gives the following error message:

│ Error: unexpected response code '400': { "Error": "AdmConProtoError: PUT requires indata, none given",
│   "code": "Client.Ibap.Proto",
│   "text": "PUT requires indata, none given"
│ }
│

Ideally I'd like to be able to send a json body where each key = '' in the data parameter on destroy, but I realize that's not especially RESTy. I'm prepared to accept an answer of out-of-scope! My backup plan is to instead use a terraform lifecycle command to just prevent destroy for the resource and do my parameter nulling via a local destroy-time provisioner.

[DRuggeri]

Hi, @broestls - thanks for opening an issue. Sadly, you're correct - the provider is written in a way that expects certain REST semantics to be used. I'm curious, though... for your use case, do you know if the Infoblox server would accept the original record as the body of the DELETE request? Not saying that this would be a definite addition to the provider, but it would be more reasonable to add a flag or behavior that sends the data field with DELETE method.