Modelling Create actions for APIs with PUT semantics

[rjlohan]

Provide guidance on how resource types should be modelled around APIs which have a HTTP PUT semantic, or "upsert" behaviour.

Specifically, give examples and guidance on how to achieve the following aspect of the Create handler contract;

A create handler MUST return FAILED with an AlreadyExists error code if the resource already existed prior to the create request.

[x6j8x]

I currently solve this by a "read" before "create", but yeah, its kind of clunky.

[benbridts]

Examples of resources that I think currently have to deal with upserting in some way:

• AWS::Lambda::Permission
• AWS::IAM::Policy
• AWS::EC2::SecurityGroupIngress
• AWS::Route53::RecordSet

[rjlohan]

There's alot of examples actually, but they are in the overall minority. Read before Create is how we recommend teams achieve this is their underlying service isn't already checking for pre-existence. There's an example of this in the AWS::Logs::MetricFilter resource.

[PatMyron]

At least for Java Plugin, @ammokhov added this to the generated CreateHandler:
https://github.com/aws-cloudformation/cloudformation-cli-java-plugin/pull/240/files#diff-29964294df5be341d1049cfd65048a6f334e57c2357fea4f107043ca97d67dc9R88
aws-cloudformation/cloudformation-cli-java-plugin#266