Is an Automated Tool for Finding API Breaking Changes in Client Code a Good Project?

There’s an important limitation: you can only reliably trace usage when you have access to the client source code or control the call sites. Public APIs often have unknown third-party consumers, so no tool can identify every affected application. Proper semantic versioning and maintaining older API versions are still necessary. You could position your project as a tool for teams that own both the API and its client applications.

This becomes a strong and manageable project if you narrow the scope to one programming language and a specific class of clients. A possible workflow is:

1. Compare two OpenAPI specifications and detect removed endpoints, renamed parameters, deleted fields, and type changes.
2. Parse the client code into an AST and locate endpoint calls, parameter references, response-field accesses, and generated-client usage.
3. Produce a report showing the likely affected files and lines along with the API change that triggered each warning.
4. Evaluate it using repositories with known API-migration commits.

Measure precision, recall, false positives, false negatives, and the time required compared with grep, dependency-only analysis, or manual inspection. Be explicit about unsupported cases such as reflection, dynamically constructed URLs, and highly dynamic languages. The project is much more convincing if it ranks likely impact locations instead of claiming to perfectly predict every failure.

The idea is useful, but API versioning already prevents many breaking changes by allowing older consumers to keep using a previous version. Your tool would be most valuable as a notification and migration assistant—something that compares API specifications, highlights breaking changes, and warns developers before they upgrade. Think of it as change tracking for API contracts rather than a complete solution to every compatibility problem.