feat: write-only attribute support

[matt-FFFFFF]

I am proposing a way to support write-only attributes in azapi_resource

Proposal

resource "azapi_resource" "write_only_mockup" {
  # ... other requried attribs
  body = {
    properties = {
      myVal = "foo"
    }
  }
  body_write_only = {
    properties = {
      myWriteOnlyVal = "bar"
    }
  }
}

The provider would merge the write-only body with the body to create the PUT request.

So the resultant body would look like:

{
  "properties": {
    "myVal": "foo"
    "myWriteOnlyVal": "bar"
  }
}

Considerations

• Would need to remove the write only values from the GET to ensure they were not persisted in state
• Conflict resolution - if values specified in body & body_write_only

Thoughts?

[cwe1ss]

Could this also work with the regular body and a separate write_only_refs = [ "properties.myWriteOnlyVal" ] field?

[matt-FFFFFF]

I think the provider schema needs to be fixed, at the attribute level. So not sure that would work.. but it's more elegant if it does

[ms-henglu]

Hi @matt-FFFFFF ,

Thank you for taking time to open this issue!

I agree with this design, and the restful provider which developed by my teammate also supported the write-only attribute in similar design: https://github.com/magodo/terraform-provider-restful/releases/tag/v0.19.0

Would need to remove the write only values from the GET to ensure they were not persisted in state

I think this should not happen. According to ARM guideline, the GET response should not return any credentials. If it happens, we should report it as a security bug.

Conflict resolution - if values specified in body & body_write_only

It seems to be a user input error? We can validate and show users error messages.

Could this also work with the regular body and a separate write_only_refs = [ "properties.myWriteOnlyVal" ] field?

I don't think so. Because azapi_resource exposes the body as a dynamic attribute, and the write-only attribute only applied to one attribute, it can't applied to part of the attribute. But actually I also prefer this design, the user experience is much better and users don't need to pay attention to splitting the input to body and write-only-body.