Is an Automated Tool for Tracing API Changes to Client Code a Practical Major Project?

The idea is useful, but API versioning already prevents many breaking changes by allowing older clients to keep using an earlier version. Your tool would be more valuable as an impact-notification or migration assistant—something that compares API specifications and warns developers about likely client-side breakage before they upgrade.

This is a solid project if you narrow it to one language and a specific API format. A practical scope would be: compare two OpenAPI documents, detect removed endpoints, renamed parameters, removed response fields, and type changes, then use an AST to find related endpoint and field references in a client repository. Report the affected files, functions, lines, and the API change that caused the warning.

For evaluation, use repositories with documented API-migration commits or create controlled changes, then compare your results with manual inspection, text search, and a dependency-only baseline. Useful metrics include precision, recall, analyst time saved, and the number of unsupported dynamic cases. The project becomes research rather than just a software tool when you measure how well each approach performs on held-out migrations.

There is an important limitation: you can only trace usage when you have access to the client source code and the code is analyzable. Public APIs often have unknown third-party consumers, and dynamic calls or generated clients can be difficult to follow. Because of that, avoid claiming that the tool finds every affected application. Present it as a system that ranks likely impact locations for supported languages and frameworks, while clearly reporting cases it cannot analyze.