AWS.jl high-level API translation issues

[omus]

Any issues noticed with translating AWS API interfaces from PascalCase to snake_case should be reported here. The following list will be updated to capture any issues that need correcting:

• IAM.create_virtual_mfadevice should be create_virtual_mfa_device
• IAM.enable_mfadevice should be enable_mfa_device
• IAM.deactivate_mfadevice should be deactivate_mfa_device
• IAM.delete_virtual_mfadevice should be delete_virtual_mfa_device
• @service Secrets_Manager must be used instead of @service SecretsManager

[omus]

Use of multiple required arguments can result in un-intuitive API calls which would be better served by keywords. e.g.:

IAM.enable_mfadevice(authentication_code1, authentication_code2, serial_number, user_name)

[mattBrzezinski]

MFADevice

In aws-sdk-js these are called, CreateVirtualMFADevice we're doing some split which ends up being MFADevice. This will apply to anything that is a sequence of uppercase characters.

SecretsManager

The underscore appears here in the generation code. We could not do the replace but rather combine and uppercase the first character of all remaining parts.

NOTE

Both of these are breaking changes and can be tracked towards a 2.0 release / build in some backwards compat

[omus]

Another example of why multiple required arguments can be unintuitive:

S3.copy_object(bucket, key, x_amz_copy_source)

Renaming the the arguments to be clearer this would actually be:

S3.copy_object(dst_bucket, dst_key, src_bucket_and_key)

Which is the opposite of the typical cp function: cp(src, dst).

[omus]

The docstring for S3.copy_object shows copy_object(bucket, key, x-amz-copy-source) which may be confusing as you can't define Julia variables with hypens. The hyphenated variable name does match they HTTP parameter so there is a good reason to have the docstring variable name match. Related to #341.