3 ms·
I mean: I don't see the point to have a new method that still gives the same (weak and misnamed) idempotency guarantees of GET. We already have GET, and a new m
by hcarvalhoalves 5y ago
I mean: I don't see the point to have a new method that still gives the same (weak and misnamed) idempotency guarantees of GET. We already have GET, and a new method isn't necessary just to pass request data.
I would rather have a method that _may_ have side-effect on the server-side, but it's actually idempotent from the client-side (as in, truly reproducible results). That already exists in the form of a PUT + some content addressing scheme, for example, but it's open to each implementation.