Reverse Document APIs - how we did it and how I’d do it now
Migrating legacy systems to microservices in pharma is a beast. I’ve seen teams struggle months trying to find who owns what API—or worse, hunt down incomplete or missing docs. Reverse-engineering became the norm: digging through logs, sniffing traffic, piecing together how parts talk. It’s frustrating, slow, and almost never fits into anyone’s roadmap.
Still, we have to release reliable, compliant microservices. Old-school guesswork and tribal knowledge won’t cut it anymore. What if AI and automation could help us map those APIs faster, clearer, with less headache?
Here’s how I’d reimagine the process today:
Capture real API traffic in Postman. This gives you the raw data on endpoints, parameters, and payloads without relying on scarce documentation.
Automate spec drafting with Swagger Inspector, which analyze traffic and generate OpenAPI specs automatically, saving tedious manual write-ups.
Leverage Copilot to turn noisy logs, legacy code comments, and raw specs into plain-language docs or usage examples developers actually understand. For example, Copilot can suggest method signatures or inline docs directly in your IDE, speeding reverse engineering without leaving your workflow.
Centralize knowledge in Confluence, with clear ownership tags and version control so everyone knows who reviews and updates what.
Automate workflows for review cycles and reminders via Slack to align busy stakeholders and get buy-in despite competing priorities.