HTTP APIs

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. Overview Before starting

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. At this point, it’s impossible to know whether the call reached the component o

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. I’ll summarize the subject in a few wo

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. Context The RFC 7807, and now the RFC 9457 which perfects it, was born after a period in which the Internet Companies have made it clear that the integration of the business, the eventual transformation of the company services into a plat