Route53 HostedZone id handling is a bit odd.

[markhibberd]

Not sure if there is a sensible way to deal with it, but the ids that are returned from API calls, can't be used on subsequent API calls without warping, example:

1. Call createHostedZone, extract out the ID, will be a string something like /hostedzone/ABC123
2. Attempt to call changeResourceRecordSets using that ID results in signature error (presumably because of incorrect escaping around /s). Stripping off the /hostedzone/ component and setting ID to just ABC123 works.

Would be good to be able to add a transformation that parses IDs correctly, or in lieu of that do something so the error isn't obscured by the auth failure. Are there any similar transformations done elsewhere? I could have a look at replicating for this, the main issue is it would break compat for anyone working around it at the moment.

[brendanhay]

It's odd indeed - completely agreed!

I'll look at how it could be transparently handled. Another example of custom types are in S3 for Bucket/Key etc: https://github.com/brendanhay/amazonka/blob/develop/amazonka-s3/src/Network/AWS/S3/Internal.hs

A newtype for HostedZoneId could be introduced in the non-generated code of amazonka-route53 with appropriate de/serialisation instances.

[brendanhay]

FYI I'm going to implement this in a manner similar to how the AWS CLI and botocore have handled it.

See: boto/botocore#398

[brendanhay]

Unlike the botocore fix I linked above where they strip prefixes during serialisation to the parameter format, I've actually stripped any prefix during deserialisation from XML. I'm hoping this is sufficient as it keeps the class instances sane, specifically ensuring that decodeXML . encodeXML == Right . id holds.