Activity › Forums › Salesforce® Discussions › What do you mean by idempotent operation in Salesforce REST API?
Tagged: Get and set Methods, idempotent operation, operations, Rest API, Salesforce APIs, Salesforce REST API
-
What do you mean by idempotent operation in Salesforce REST API?
Posted by chanchal kumar on July 10, 2018 at 1:03 PMWhat do you mean by idempotent operation in Salesforce REST API?
shariq replied 7 years, 7 months ago 6 Members · 5 Replies -
5 Replies
-
Idempotent operation in rest API are-
- GET
- PUT
- DELETE
- HEAD
- OPTIONS
- TRACE
POST is not an idempotent operation in rest API
- [adinserter block='9']
-
Hi Chanchal,
Idempotence is an important design consideration when building reliable distributed systems. This post introduces you to idempotence, explains idempotence in the context of Salesforce system integrations, and gives you links to some additional resources that you can review for more information about idempotence.
From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (no side effects), the response itself may not be the same (e.g. a resource’s state may change between requests).
The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) on subsequent calls, unless the service is configured to “mark” resources for deletion without actually deleting them. However, when the service actually deletes the resource, the next call will not find the resource to delete it and return a 404. However, the state on the server is the same after each DELETE call, but the response is different.
Thanks.
-
From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (no side effects), the response itself may not be the same (e.g. a resource’s state may change between requests).
The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) on subsequent calls, unless the service is configured to “mark” resources for deletion without actually deleting them. However, when the service actually deletes the resource, the next call will not find the resource to delete it and return a 404. However, the state on the server is the same after each DELETE call, but the response is different.
Thanks.
-
Hello,
Idempotence is a property that creates identical side effects whether you have one or many results. PUT has this characteristic, while POST creates new resources infinitely. In general, POST works best for resource creation, while PUT handles updates.
Thanks.
-
Hi,
Idempotence is a funky word that often hooks people. Idempotence is sometimes a confusing concept, at least from the academic definition. From a RESTful servicestandpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result
Hope this helps.
Log In to reply.