A Java geek

I try to constantly deepen my knowledge of HTTP and REST. Recently, I stumbled upon the list of all registered HTTP Headers. This post is dedicated to the Vary HTTP Header. The problem Two years ago, I wrote about web resource caching server-side. The idea is to set up a component between the client and the upstream to cache previously computed results to avoid overloading the latter. Depending on your infrastructure and requirements, this component can be a reverse proxy or an API Gateway.

I recently read 6 Ways To Pass Parameters to Spring REST API. Though the title is a bit misleading, as it’s unrelated to REST, it does an excellent job listing all ways to send parameters to a Spring application. I want to do the same for Apache APISIX; it’s beneficial when you write a custom plugin. General setup The general setup uses Docker Compose and static configuration. I’ll have one plugin per way to pass parameters. docker-compose.

I wrote previously about libs for error management in Rust. This week, I want to write about the try block, an experimental feature. The limit of the ? operator Please check the above article for a complete refresher on error management in general and the ? operator in particular. In short, ? allows to hook into a function call that returns a Result: If the Result contains a value, it continues normallyIf it contains an error, it short-circuits and returns the Result to the calling function.

The book Design Patterns: Elements of Reusable Object-Oriented Software was one of the texts that changed how we think about software design.

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.