The most common way to manage changes of an API is to use versioning. Using versioning is basically a way that you can let the developers of the clients of the API know, right from the beginning, that there might be changes in the API that will be backward incompatible as the business model evolves. However, this doesn't mean that you cannot add new APIs to the same version. In fact, you don't have to change the version as long as you do not create backward incompatibility issues in your API. So, versioning is not the cause of backward incompatibilities. On the contrary, it is a way to manage that issue. It is often a lack of consideration during the API design or the changes of the application's business models that introduce backward incompatibilities.

Anyway, once you have a new version, you should announce it to the developers within plenty of time so that they can test and provide feedback before the new version goes live in production. Usually, you will keep the old version running for a period of time so that developers can finish the migration before you retire the old version. It is true that even though you leave plenty of time for the migration, there will still be clients that are stuck with old versions. For example, it is often hard or even impossible for those embedded systems to upgrade to a new version of the API. So, what should you do in that case? From a technical perspective, you can create an autoupgrade mechanism so that the application living in the embedded system can be upgraded as required. Or you can choose to use HATEOAS and provide client libraries to make it easier for those developers to consume your APIs and avoid API misuse. At a certain point, a business decision needs to be made upon which the old version should be shut down.

In reality, there is seldom an API that has pure evolvability plus longevity without breaking clients. Changes are inevitable. Business models can change, the way end users interact with the clients can change, and hence the way of consuming APIs can change. We cannot avoid changes, but we can manage them. And certainly, versioning is not a perfect solution. It is not a silver bullet. But it is an effective way of managing API changes. 

There are two ways to manage versions. One is to include the version number in the URI, for example, https://api.examplebucks.org/v1/orders or https://api.examplebucks.org/orders?version=1. The other way is put the version number in an HTTP request header, for example, X-API-Version. However, this could become a problem when the clients forget to include the version number in the header. You can assume that, without the presence of such a header, the client is requesting the API of the latest version. However, once you upgrade your APIs to a new version, those clients that haven't migrated will break. Preferably, making the version number explicit in the URI is better than being implicit by keeping it in the header.

On the other hand, for a monolithic application where you have the control of both the frontend and the backend, you don't need to use versioning in the API. This is because the API is for internal usage and you can make changes to both the API and the clients at the same time and deploy them together. However, if you're building mobile apps, you might want to treat them separately. This is because, even though you have updated the API version in the mobile app and published it in the app store, end users might be stuck with an old version of the app. Due to the scope of this book, we will not go into the details of mobile apps here.

To sum this up, for public APIs, use versioning, even if your business model is relatively simple at the moment. Remember, things change. For internal APIs, do not use versioning when you have control of the clients.