I think one of the biggest pain points in working with microservices is making sure that the APIs are well-documented and APIs do not change their behavior without affecting downstream applications. This problem becomes amplified when you have many services that are interdependent on each other. Perhaps at that point you doing microservices wrong, but I digress.
Let's say we have inherited 20 microservices that are owned by different teams and there is no clear documentation about which application uses which other application's API endpoint. Is there a prescribed way of documenting this? At first I thought of analyzing each application's endpoints and adding them to a database table, then creating FK relationship among each application and an application's route on a many-to-many table (almost all of these are rails apps). But I am not sure if this is a good way to handle this, or am I re-inventing the wheel here.
In retrospect, this might be a not so bad way to document application interaction if you are starting with microservices from scratch. This would just enforce that a single source of truth is maintained via the use of a database and any changes to the endpoints would be performed in the application in conjunction with the change in database. Thoughts?