Changing API endpoints
Let's say your working on a new feature, or a nasty bug in your API. You'd like to update an API endpoint, but it's already in use on production.
You're working in a legacy codebase, there's no versioning mechanism. If you change that endpoint and it's released to production, your frontend will immediately use those changes — except that it's not ready for those changes and will still be looking for old keys.
For you and your team, versioning is not an option — the codebase is too complex. You should be able to release your frontend and backend independently. How do you go about releasing this new feature, or fixing that bug?
Note: if your API is used outside of your application, these solutions are not for you. I recommend reading up on and implementing API versioning.
Backwards Compatible API changes
One way is to apply the changes to your endpoint in a backwards compatible way. Example time!
Let's say you have thumb: image.png in your response, but you want to return an array of thumbs instead of just the single image. Your frontend depends on that thumb key to be available — so don't remove it! Instead, you can add the new thumbs key to the response.
Once your API changes have been deployed to production, your frontend can be updated to use the new thumbs. Once that code has been deployed, you can remove the obsolete thumb from your API response!
Forwards Compatible frontend changes
A different approach is to update your frontend first. I like to call this "Forwards compatibility". Take the example above: instead of updating your API first, you anticipate the change in the frontend.
Now your API can be updated whenever! Don't forget to remove the condition from your frontend code when everything is done.
Conclusion
These are two different ways to update your API without versioning. If your API is used by more than just your internal application(s), please have a look at versioning — this won't fix your problem.
