4 ms·
I thought the chosen example for idempotent requests was a bit funny as I don't think POST is necessarily idempotent and depending on your specific use case mak
by Glyptodon 7y ago
I thought the chosen example for idempotent requests was a bit funny as I don't think POST is necessarily idempotent and depending on your specific use case making it so may or may not be easy.
- seph-reed 7y agoIt requires passing in an id of some sort. Client generated ids are cool for a lot of things; I wouldn't use them for everything.
- Glyptodon 7y agoCompletely agree with you.
- paulddraper 7y agoPOST is explicitly not idempotent.
- AgentME 7y agoPOST isn't required to be idempotent, but to be clear it's not improper to make an API with idempotent POST endpoints.
- Glyptodon 7y agoWhich is exactly why it's a fairly unusual choice for an example.
- AgentME 7y agoIt would be weird if he used a method like GET which is normally idempotent. People already make those be idempotent, so they would miss that the point is that a good API has all idempotent endpoints, POST and not.
- Glyptodon 7y ago...and the given example of something that should be idempotent is posting to create a new VM instance. Which you certainly may do. It's just a funny choice of example since that's the one example where the behavior he describes is potentially expected.
- mozey 7y agoThe article doesn't mention POST. It says "the first time we call it the VM is created. The second time it is called the system detects that the VM already exists and simply returns without error". Makes more sense to assume it means PUT, defined as "The HTTP PUT request method creates a new resource or replaces a representation of the target resource with the request payload"