Every API that lives long enough faces the same tension. The product changes. Customer requirements evolve. Performance work forces backward-incompatible refactors. And on the other side of every one of those changes are integrators — customers, partners, internal teams — who wrote code against last year’s shape of your API and do not plan to rewrite it on your schedule. API versioning is the discipline of changing what you need to change without unilaterally breaking those integrators. It is less about picking a pattern and more about picking a commitment: how long will we carry old shapes, how loudly will we communicate the end, and how seriously will we enforce the retirement when it arrives? Three versioning patterns dominate the landscape. None is universally correct. Each fits a different kind of API program. URI versioning The version lives in the path. /v1/orders and /v2/orders are distinct URIs that can be served by distinct code paths, cached independently, and routed at the load balancer. Pros.…