There is definitely multiple ways to handle that, but splitting your API into frontend and backend seems to be a common and good approach. The backend is basic

There is definitely multiple ways to handle that, but splitting your API into frontend and backend seems to be a common and good approach. The backend is basically the "real" internal API, subject to changes. The frontend consists of nothing more than forwarding functions, that take their input from the outer world and translate it to backend API calls. How you organize Code reuse depends on the language, but inheritance is not a bad way to do it, although you might run into trouble with the size of your hirarchy. You can circumvent that with maps of functions/lambdas, like prototyping in Javascript. For testing you then have your usual set of tests for the backend, but for the frontend you just test if the translation between public and internal API is correct. Very easy to test for in most cases. If you then organize your tests exactly like your frontend Version, i.e. some kind of inheritance, you only ever have to add tests for the changes in your new Version. It is definitely more work than just having one ever changing API, but it's not that much of a hassle imho.