fix: store raw response in APIError during JSON parsing

[neilmartin83]

Change

Thank you for your contribution !
Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context.
List any dependencies that are required for this change.

Type of Change

Been meaning to dig into this one for a while... :-) When working with endpoints that give JSON responses, raw_response was being returned as an empty string, for example:

jamfpro_sso_settings.okta: Modifying... [id=jamfpro_sso_settings_singleton]
jamfpro_sso_settings.okta: Still modifying... [id=jamfpro_sso_settings_singleton, 00m10s elapsed]
╷
│ Error: failed to update SSO settings: failed to update sso settings, error: {"status_code":400,"method":"PUT","url":"https://ajksxfz.fleet.jamf.build/api/v3/sso","message":"API Error Response","raw_response":""}

This change just makes sure we always output the raw response. I think it fails because the APIError struct does not match the fields we get from a Jamf Pro JSON error response. But I didn't want to change that in case it breaks response handling from other APIs this client is used with.

Now a TF error looks like this instead (populated raw_response field) which is extremely helpful for debugging/troubleshooting provider/API/TF module issues downstream:

│ Error: failed to update SSO settings: failed to update sso settings, error: {"status_code":400,"method":"PUT","url":"https://ajksxfz.fleet.jamf.build/api/v3/sso","message":"API Error Response","raw_response":"{\n  \"httpStatus\" : 400,\n  \"errors\" : [ {\n    \"code\" : \"INVALID_METADATA\",\n    \"description\" : \"Unable to unmarshall metadata\",\n    \"id\" : null,\n    \"field\" : \"idpUrl\"\n  } ]\n}"}

Please DELETE options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update (Wiki)
• Refactor (refactoring code, removing code, changing code structure)

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• My corresponding pipelines / checks run clean and green without any errors or warnings
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (readme)
• I did format my code

[neilmartin83]

Started looking at having a generic/agnostic way to wrangle JSON error responses but it started to go down a rabbit hole with all the cleanup/formatting to deal with.

So have backtracked on this after a bit of thought - instead just updated the APIError struct to handle missing fields that come from most Jamf Pro JSON error responses - no changes to any other parts of this package. From what I can tell in the schema, where documented, JSON error responses all follow this structure:

{
  "httpStatus": 400,
  "errors": [
    {
      "code": "8675309",
      "field": "Name",
      "description": "I've just picked up a fault in the AE35 unit. It's going to go 100% failure in 72 hours",
      "id": "3"
    }
  ]
}

An example error from the provider during an apply now looks like this, which is much more readable and I don't think this will negatively impact other projects/APIs that use this client:

jamfpro_sso_settings.okta: Modifying... [id=jamfpro_sso_settings_singleton]
jamfpro_sso_settings.okta: Still modifying... [id=jamfpro_sso_settings_singleton, 00m10s elapsed]
╷
│ Error: failed to update SSO settings: failed to update sso settings, error: {"status_code":400,"method":"PUT","url":"https://REDACTED.jamfcloud.com/api/v3/sso","httpStatus":400,"errors":[{"code":"INVALID_METADATA","field":"idpUrl","description":"Unable to unmarshall metadata"}],"message":"API Error Response","raw_response":""}
│ 
│   with jamfpro_sso_settings.okta,
│   on sso_settings.tf line 1, in resource "jamfpro_sso_settings" "okta":
│    1: resource "jamfpro_sso_settings" "okta" {
│ 

Specifically we now have this part which is unmarshalled to : "httpStatus":400,"errors":[{"code":"INVALID_METADATA","field":"idpUrl","description":"Unable to unmarshall metadata"}]

Please do let me know what you think.

[ShocOne]

Approved