iil3i/api-proxy repository overview

⁠Motivation: Versioning for public APIs

In the context of Lean Development it is often discussed where to draw the yagni-Line: you want to ship early, and for the first version, why worry about how you are going to deal with breaking changes that might occur at some point in time in the future? It is time consuming and it might lead to a less forgiving API concept than needed at the first glance.

On the other hand, setting clear boundaries for communication between clients and your public api from the beginning comes with the benefit it prevents confusion on the API-consumers side when a breaking API change is about to happen. In that case you'll want to know how to run multiple versions in parallel for the transition time and how clients are going to request the exact versions they are known to play well with.

More important, you want to ensure your API-consumers are aware they need to define a version when communicating with your API. In the case of all examples provided here, that is via Accept Header based content negotiation.

See interagent/http-api-design⁠ guide for more context on the reasoning.

So I wanted to come up with a quick-and-easy way to incorporate a reverse proxy that serves as a baby-steps-API gateway for the early life time of public APIS. The days when it seems too much effort to go for a more sophisticated API-Gateway like krakend⁠, Kong⁠, Traefik⁠, Caddy⁠, Linkerd⁠, Fabio⁠, Vulcand⁠, Netflix Zuul⁠ or similar⁠

See github repo⁠ for details and usage examples⁠