Posted on Sep 25 • Originally published at api7.ai When you develop Apis, you sometimes change things that might cause problems for current API consumers. Evolving your API product without affecting current users is essential, otherwise, they might lose trust in your offer. It's impossible to altogether avoid these problems but you can minimize the impact or catch some catch-Breaking changes before they happen. Breaking changes need to be identified during the development phase, and if they happen, the API gateway should handle them to ensure client applications remain unaffected. In this article, we will explore some best practices and strategies to prevent API-breaking changes and how to handle them using the Apisix API Gateway.Software products evolve consistently, and their APIs are no exception. These APIs serve as the primary interface through which external API consumers engage with your system, mirroring any product changes. There are various reasons for these API modifications, including technological improvement, shifts in business direction, critical bug resolutions, and more. In simple terms, a breaking change is when you change your API and it might cause problems for client apps using it. Some of these changes are easier to spot than others. Here are some examples of breaking changes:Every change in API has the potential to break a client application. If you use API Gateway like a front door for all the backend APIs, the gateway knows where to forward the request based on a set of rules defined in a route configuration and it is the right place to handle breaking API changes. Let’s see how we can use APISIX to identify some API changesDefining strict schemas for your routes allows you to ensure request and response structures are as expected. Use the request-validation plugin to validate incoming requests and the response-rewrite plugin to rewrite the API response based on certain conditions.APISIX supports various logging plugins, such as http-logger, elasticsearch-logger, file-logger, and more. Set up a logger to store the API request and response data and analyze logs regularly to detect changes in request/response headers, payload structures, or any other unusual patterns.Monitor the routes passing through the gateway. If a previously available route suddenly starts returning 404 errors, it's a potential sign that the API has undergone a change or an endpoint has been deprecated. Enable the API health check feature to monitor continuously the overall health of upstream nodes. If one of the nodes starts to fail, responding faster or slower than usual, it might indicate a change in the underlying backend service's processing. Integrate APISIX with monitoring tools like Prometheus using the prometheus plugin. Set up alerts based on metrics, such as an increased rate of 4xx or 5xx errors, which could indicate breaking changes in your API.API versioning is the practice of managing changes to an API and ensuring that these changes are made without disrupting API consumer apps. There are various methods to set up versioning with APISIX, like using URI paths, query parameters, headers, or picking the content type. For instance, you might have web addresses like /v1/users or/v2/users to show your API's version. By having these versions, you can offer more than one option of your API, API consumers to decide when to upgrade to the latest version at their own pace. APISIX can easily redirect all traffic back to the old, stable version of the API until you address the issues in the new version that makes your APIs backward-compatible. Employ APISIX to retain the old compatibility while rolling out the new changes if you detect issues in the new version, the traffic-split plugin allows for a quick rollback. Before removing or altering features, mark them as deprecated, giving consumers adequate time to adapt. With the help of the APISIX, we can configure the route to communicate about its future deprecation and its replacement. For that, APISIX offers the response-rewrite.While you might wish that pull request reviewers would spot any breaking changes, relying solely on this method is not certain and might lead to failure eventually. If you have OpenAPI/Swagger documentation for your APIs, these can be version-controlled and included in a CI pipeline. APISIX doesn't natively support direct integration with version control systems like Git for API specification changes. However, you can set up a process outside APISIX. Tools like Oasdiff or Bump can identify changes in API specs, and trigger a CI pipeline (add GitHub Action) that runs tests against the route endpoints in APISIX to ensure no breaking changes are introduced. Postman contains a template to automatically check the current version of your API for breaking changes and describes how it works in this article. You add the detector to the CI pipeline as an extra step. Every time your pipeline executes, the breaking change detector will analyze the present API spec against the previous one and notify you of any differences. Depending on your development stack, there are other libraries to compare OpenAPI specifications. This article explains well how to catch them in practice using tested deployment strategies before taking new changes to production.Detecting breaking API changes is important for maintaining trust with API consumers and ensuring the success of your service. By integrating APISIX's capabilities like request validation, versioning, logging, monitoring, and alerting with techniques like automated API contract testing, you can ensure your APIs evolve without negatively affecting your clients. Keep up APIs healthy with APISIX and PrometheusRequest validation in API Gateway🙋 Join the Apache APISIX Community🐦 Follow us on Twitter📝 Find us on Slack💁 How to contribute pageVisit my blog: www.iambobur.comTemplates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Vasileios Kagklis 🅰 - Sep 21 Ramakrishnan83 - Sep 24 Francisco Inoque - Sep 20 Scofield Idehen - Sep 23 Once suspended, apisix will not be able to comment or publish posts until their suspension is removed. Once unsuspended, apisix will be able to comment and publish posts again. Once unpublished, all posts by apisix will become hidden and only accessible to themselves. If apisix is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Bobur Umurzokov. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag apisix: apisix consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging apisix will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.