Connecting is good, but separating can be, too
I like working on integrations and APIs because I believe in the power of connecting: Legacy software containing accumulated business value with modern components using the potential of new technology, addressing the current trends and market opportunities. Or internal software with external services that are more efficient to outsource.
Integration is also a very important aspect of applications and systems based on the microservices architecture. However, microservices, after their initial boom, started facing criticism and monolithic applications are back in the game.
If you, like me, are fascinated by (astro-) physics, you might like this summary of pros and cons of splitting versus keeping services together.
Unfortunately, I have experience with both sides of suboptimal microservice granularity: A service shared by multiple teams and many services with unclear business boundaries, developed by one team and sharing database tables.
Many of the factors to consider when deciding about the granularity of your services are technical. However, from my experience in almost all projects the actually biggest problems were not technical but rather related to people.
This brings me to Conway's law
If your architecture is not aligned with the communication structure of the people (organisation), the communication barriers will find their way into the software. The different teams will try to guard their territories in the code and build barriers to protect them.
A good architecture embraces Conway's law by making the code representations of the cross-team communication barriers explicit, organised and standardised. Otherwise, the barriers will still be there, but they will take the form of chaotic invisible minefields, sometimes battlefields.
Maybe you can enforce a modular monolith using tools like Spring Modulith or ArchUnit
But there will always be many situations when the business functionalities or implementations assigned to different teams will overlap. There will be many details that will need alignment, many meetings to decide which team's approach is the one to go with.
Even a monolith usually needs to integrate via remote APIs on which the teams will need to agree. Then there is test automation, local development setup, coding conventions and quality checks...
All the things that are not visible by the customers or users of the service, but still cannot be decided within one team in a quick and agile way.
If the project or company is already big enough to need many teams and have the resources to support the microservices infrastructure (for example Kubernetes) then microservices that are mapped to cohesive business functions and having one team as an owner can increase both the efficiency of development and happiness of the developers.
If you accept that dividing the code into microservices can be a good thing, you should do it well and that includes the API design.
A well-designed API and its every endpoint only contains things that are really needed and not more. Such an API is more secure and easier to evolve (maintain). It avoids unnecessary coupling (dependencies) between the services it connects and between the teams developing them. That will liberate the teams to concentrate more on their implementations and less on the dependencies or conflicts with other teams.
Not controlling what you expose in an API is one of the details that are easy to miss when you start, but hard to fix later when the API is in use.
It is also one of the details mentioned in my talk 12 overlooked API details that can get you in trouble.