> That pretty much makes all internal APIs and code like Public APIs as a product (...) No. Different versions are not different products. They are the exact s

> That pretty much makes all internal APIs and code like Public APIs as a product (...) No. Different versions are not different products. They are the exact same product, provided in a way that delivers features in a way that won't break clients. > (...) adds a huge costs in terms of initial API designs (...) Obviously not. From the producer side, all it takes to support versioning is picking up your versioning strategy and sticking with it. This can mean providing an endpoint through a different path parameter, reading a request header, or even get the version through a query parameter. Does it take you much design work to add a "v1" in a URL path? How about reading a request header? Does passing a query parameter require meetings to review designs? Some frameworks even explicitly support versioning as a high-level concept and make it a part of their routing strategies. Copy the source file of a controller to another folder, change it's namespace to avoid conflicts, add a tag to the class, done. You just released a new version of your API. > (...) assumption validations, because you can't make any mistakes at all. You somehow managed to get it entirely backwards. With versioning, you can afford making all kinds of mistakes all the time. Breaking interfaces is no longer w concern. You release your changes to an upstream dependency/producer with zero use, downstream dependencies/consumers can gradually switch as their test plans allow, and if any problem is detected then this can be worked out before either consumers go live or producers receive production traffic. More importantly, you have your old stable versions ready to roll back.