Well, I can think of two reasons immediately. The first is in hermetic testing environments, where you may have two tests where you’d like to see the same entity. You can’t always know the order in which tests execute. That means that either seeding operations should be idempotent, or you’d have to handle setup outside of the individual tests. (Which makes the tests, overall, harder to read.)
Another reason could be for resiliency. You may add a retry mechanism into your code in the frontend, to increase resiliency. If a request returns a 500, you don’t know if the entity is created. (The server error could occur in post-processing.) You either have to rely on the creation to be idempotent, or you have to make an additional round-trip. Using a create-or-update mechanism reduces latency and simplifies error-handling code.
Well, I can think of two reasons immediately. The first is in hermetic testing environments, where you may have two tests where you’d like to see the same entity. You can’t always know the order in which tests execute. That means that either seeding operations should be idempotent, or you’d have to handle setup outside of the individual tests. (Which makes the tests, overall, harder to read.)
Another reason could be for resiliency. You may add a retry mechanism into your code in the frontend, to increase resiliency. If a request returns a 500, you don’t know if the entity is created. (The server error could occur in post-processing.) You either have to rely on the creation to be idempotent, or you have to make an additional round-trip. Using a create-or-update mechanism reduces latency and simplifies error-handling code.