Add ignore_server_additions attribute to prevent drift from API defaults

[jor2]

Summary

When REST APIs return additional fields beyond what was configured (such as default values, timestamps, metadata, or computed properties), the provider detects these as drift. This causes:

• Perpetual diff between configuration and state
• Unnecessary plan changes on every terraform plan
• Potential resource recreation on terraform apply

This PR adds a new ignore_server_additions attribute that, when set to true, ignores fields added by the server that weren't present in the user's original configuration.

How it differs from ignore_all_server_changes

Attribute	Ignores server-added fields	Ignores server-modified fields
ignore_all_server_changes	Yes	Yes
ignore_server_additions	Yes	No

The new attribute is more targeted - it allows you to still detect when the server modifies a field you explicitly configured, while ignoring additional fields the server adds.

Example usage

resource "restapi_object" "example" {
  path = "/api/objects"
  data = jsonencode({
    name = "my-resource"
  })
  
  # Ignore server-added fields like created_at, updated_at, status, etc.
  ignore_server_additions = true
}

Changes

• Added ignore_server_additions attribute to the resource schema
• Modified getDelta function to accept the new parameter
• Added comprehensive test cases for the new functionality
• Updated import test to include the new attribute

Test plan

• All existing tests pass
• New unit tests cover various scenarios:
  • Server adding single/multiple fields
  • Server adding nested fields
  • Server modifying configured fields (still detected as changes)
  • Interaction with ignore list

Fixes #319

[DRuggeri]

Nice - this is a great addition, @jor2
I do wonder, though... perhaps this should be default behavior? @michaelPotter - what are your thoughts since you worked on the original implementation? I guess I would expect sever additions, which are not represented in my request in data at all, to not trigger the drift detection.

This is a good time to discuss the default behavior and document it since I plan to cut a v3 of this provider along with the migration to TFSDKv2

[michaelPotter]

Hi there! thanks for the consideration @DRuggeri !

I suspect most cases of "server added fields" are for metadata like timestamps - and this would be useful there - but I also worry there are valid cases where this isn't really what you'd want.

For example consider a hypothetical API resource with an optional TTL field and omitting this field might have semantics meaning "no expiration". Say you intentionally omit the TTL when you create the resource, but later someone/something sets that field out of band, like in a dashboard UI or there's a bad script or something. I personally would expect that the next time you go to terraform apply, the provider would attempt to revert that change and remove the field.

For that reason, my opinion is that it probably shouldn't be default, but I do think it's a good feature! Especially for @jor2's usecase where a PATCH request might return waaay more fields than you sent in.

Also @jor2 - this doesn't detract in any way from your hard work or your PR (I think it's a great improvement!) - but I don't see that you've mentioned the ignore_changes_to parameter in your issue or PR; were you aware that server added fields can also be ignored by listing them there? If not, that simply indicates to me that the documentation could be improved. (ignore_server_additions is great and waaay better than listing a thousand fields for your request lol)

[jor2]

Hi @michaelPotter thanks for the feedback! yeah, the main issue was I would have to go examine the response fields every time I want to use the restapi provider and add all those fields I don't care about to ignore_changes_to, most of these fields are irrelevant and shouldn't be causing drift, like timestamps etc. Their response could be updated with new fields causing drift during their next update if they decide to rename one of their response fields etc. Just felt like this might be easier for most users and doesn't really conflict with any existing logic.

[DRuggeri]

Awesome, guys, thanks for the dialog. It makes sense to leave it opt-in... and also good to have the option that tracks just your data elements ignoring anything the server tacks on.

I've merged this code into the new Terraform Plugin Framework branch and will release it soon!

[ocofaigh]

@DRuggeri looks like this made it into the v3 release candidate. Just wondering if there is any rough ETA yet for v3 GA release? Are we talking weeks or months? Thanks in advance.

[DRuggeri]

Spot on, @ocofaigh - it's in the v3 RC. I planned to let the RC sit and stew for a few weeks before releasing it. We've had some issues crop up, which @jor2 has already helped address. I'd like to get #347 addressed, cut a new RC, and assuming no new reports filter in, release that in about 2 weeks.