Change log:

Introduction

The purpose of this section is to describe how to configure idempotency of REST endpoints. 

Overview

Idempotency means that sending the same request multiple times will produce the same result, without changing the state of the server or the resource. 

Idempotency is important for REST APIs in general, but especially for event-driven architecture, where multiple components may communicate with each other through messages that trigger REST API calls. If a message is lost, duplicated, or delayed, it may cause inconsistent or unexpected outcomes, such as data corruption, duplication, or loss. By ensuring that your REST APIs is idempotent , one can reduce the risk of these errors and improve the reliability and resilience of the system.

GET, HEAD, OPTIONS, PUT and DELETE are idempotent methods. POST is not idempotent.

One of the best practices for designing idempotent and safe REST APIs is to use the appropriate HTTP methods for regular operations.,

Prerequisites

This feature is avaible for REST depending on Core 12 or aboveavailable from Rator Core version 12 and up

Enablement

By default, idempotency of the POST requests is disabled, as it adds some overhead by persisting each POST response. To enable it, the following parameter needs to be set in Properties configuration file:

rest.api.idempotency.enabled=true

Also, to uniquely identify each idempotent request, the Idempotency-key header paameter parameter needs to be sent in the request.

The value of this parameter should be a unique random string, recommended in a form of UUID v4.

Here is an example (curl command, only header parameter):

...

Note: this header should only be sent for POST requests, otherwise it will be ignored.

Error handling

When concurrent requests (with the same Idempotency-key) happen, a specific error will be returned :

...

Solution; Generate a new Idempotency-key and resend the request.

Retention and Cleanup

A database job is responsible for removal of old/historical IDEMPOTENT_ACTION records.

The recommendation is to keep this table as small as possible, for performance considerations.

Reference: