When trying to create the same resource twice, all request should report the same status instead one failing, one succeeding.
In AWS, their APIs allow you to supply a client token if the API is not idempotent by default.
See https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_I....
Before I quibble with the idempotency point: I agree with this, entirely, but it is what it is and a lot of software has been written against the current behavior. So I'll cite Hyrum's law here: https://www.hyrumslaw.com/
> GCP control plane is generally not idempotent.
The GCE API occupies an odd space here, imo. The resource being created is, in practice, an operation to cause the named VM to exist. The operation has its own name, but the name of the VM in the insert operation is the name of the ultimate resource.
Net, the API is idempotent at a macro level in terms of the end-to-end creation or deletion of uniquely named resources. Which is a long winded way of saying that you're right, but that from a practical perspective it accomplishes enough of the goals of a truly idempotent API to be _useful_ for avoiding the same things that the AWS mechanism avoids: creation of unexpected duplicate VMs.
The more "modern" way to do this would be to have a truly idempotent description of the target state of the actual resource with a separate resource for the current live state, but we live with the sum of our past choices.
You're right, we did it wrong.
// And paradoxically makes engineers like you.
Disclaimer: I work on GCE.
This is nicer!