Sharing API Services

API Sharing Strategy

So far, in our example MTAEDA application, we’ve focused on various domain information that’s closely interrelated. As a lone developer, we can probably recall most of the API endpoints we created in one microservice when we come to utilize them in another microservice. However, in practice, we don’t develop in isolation. One of the key benefits of microservice architecture is the ability to divide and conquer by assigning smaller domains to different teams (or lone developers). In fact, we don’t want to limit the understanding of our APIs to just the teams associated with the main solution but to any other teams that might be able to benefit from these same services.

Let’s imagine a scenario where there’s an intent to conduct a study on transit foot traffic patterns and how they correlate with major sporting events around various cities. We already have many services designed to support the backbone of the transit management system. There’s bound to be a level of reuse for the purposes of this study. Accessing those services and capabilities should not depend on institutional knowledge and scanning through piles of documentation and code. These services should be easily discoverable, well-defined, and published.