Service API Patterns, Protocols, Coupling Types, Metrics > Fundamental Service API Patterns > Idempotent Capability
How can a service capability safely accept multiple copies of the same message to handle communication failure?
Network and server hardware failure can lead to lost messages, resulting in cases where a service consumer receives no response to its request. Attempts to reissue the request message can lead to unpredictable or undesirable behavior when the service capability inadvertently receives multiple copies of the same request message.
With the application of the Idempotent Capability pattern, service capabilities with idempotent logic enable repeated message exchanges to be safely accepted because each response message provides the same result. Idempotency is an important concept within Web architectures and messaging frameworks in general. The value of this pattern is that it brings the rule of idempotency to the service API level by building in a level of communications reliability between the consumer and service without requiring that they share a persistent connection (Figure 12.21).
A REST service offers idempotent capabilities alongside a non-idempotent capability. The GET and PUT capabilities can be safely retried because they are idempotent. The POST capability is not idempotent and must not be retried unless each request is associated with a unique identifier. Such an identifier would need to be incorporated into the service’s session state and must be synchronized between service instances alongside changes to the value.