Last week, I wrote an analysis of the IETF Idempotency-Key specification. The specification aims to avoid duplicated requests. In short, the idea is for the client to send a unique key along with the request: If the server doesn’t know the key, it proceeds as usual and then stores the responseIf the server knows the key, it short-circuits any further processing and immediately returns the stored response This post shows how to implement it with Apache APISIX.

The first rule of distributed systems is 'Don’t distribute your system'. Designing distributed systems right is infamously hard for multiple reasons. The idempotency concept For example, a call to a function can succeed or fail in non-distributed systems. Once you move the called function to a remote component, a third option appears: you call the remote function but get no response from the component.

In my previous post Evolving your APIs, I mention the main API versioning approaches. During the talk of the same name, I sometimes get some questions on the subject. In this post, I’ll detail each of them. I assume readers know the reasons behind versioning, semantic versioning, and product lifecycle. If not, I encourage you to read a bit about these themes; in particular, chapter 24 of the excellent API Design Patterns book focuses on them.

The positive experience of RFC 7807, whose journey began in 2016, is concluded (deprecation) but also confirmed with a new official proposition: the RFC 9457. The changes made are small but it is a suitable opportunity to analyze the evolution of this topic.