[]byte would be preferable to *string as the type of Message Bodies

[endophage]

A number of the services (SQS is the one I've been dealing with recently), appear to use *string as the type for a message body. Per @jasdel this is apparently to help enforce unicode encoding of the body.

However, with many of these services I and everyone I've discussed them with, put our own encoded (JSON, XML, etc...) data into the body and need to parse it when consuming. Go's encoding package and it's sub-packages consistently use the []byte type as input and output.

This creates the problem that we frequently have to type cast between string and []byte (and vice versa when initially creating the message body), causing additional memory allocations, not overly concerning for things like SQS with 256KB max message size, but not great. More frustratingly though, code ends up sprinkled with what should be unnecessary casts, which are just ugly.

[jasdel]

Discussion original started in #363 for extra context

[jasdel]

@endophage thanks again for this request. These fields being *string instead of []byte is a representation of the underling wire service protocols. Since the API service clients are generated from service API models their representation will be very similar to the the model definitions. This is also why pointer types are so commonly implemented in the SDK instead of value for future optional parameter support. In this case the message body parameter is a string within the service's model.

The SDK does have the ability to create customizations, overriding what is specified in the model. In a few specific cases this functionality is used to modify the ingested models specifically based on the SDK's capabilities. This functionality is used sparingly to prevent creating situations where maintainability is hampered, or preventing backwards incompatible breaking changes. There are numerous other types this style of customization could be applied to also. Each one brings the SDK further away from the service API model's definition, and increases the maintenance burden. Increasing the risk inconsistencies in the API which cannot be corrected without a breaking change.

Because of this we would like to hold off making customizations to the service API model like this. Similar types such as Policies and the more extreme CloudFormation Templates would be better and more completely served by concrete types or builders to address their pain points.

[jasdel]

Thanks again for the feature request. I'm going to close this issue for now since we don't plan on adding this customization to the SDK. Please let us know if you have any addition questions, feedback, or ideas how the SDK can be improved.