API Breaking changes

[chesterbrook31]

Supposed your organization have this API and clients/consumers are already using it.One day your organization need to make some upgrades that will cause the existing API to break for your existing consumers.One thing I have in mind is roll the upgrades in a V2, and tell them. Give them time to adopt/update.and then eventually, roll it to V1 once everybody adopts (but then they will have to make another change on their side).Or do you really need to do API upgrades after you roll out to prod and have dozens of cosumers using it already?

[#2]

In Apigee normally the major backend changes can be maintained with versioning. Think like the one which is the existing one is having base path /v1/xyz. Then the new one will be like /v2/xyz. The best way is to make v1/xyz and v2/xyz both live until all the users migrate to v2. Once all migrated undeploy the v1 proxy.

[chesterbrook31]

I guess one thing I wanted to ask opinion for is, should we do API upgrades/changes once it goes public and already being consumed by number of paying clients?

[#4]

Change is a continuous process. Apigee provides revisions for minor changes and for major backend changes versioning is there. You need to do the changes if required and best practice is to do the changes in lower environments and in production, you should do in a swift manner during low business hours with change window. When one revision is deployed you can work on a new revision with changes and deploy once testing is done and ready to go live.