> I think this is too strong of a definition because then everything is a monolith.
Yes... exactly. More things are monoliths than we want to admit.
> We need a definition of what it means for two services to communicate while being “uncoupled”
Take a dead simple example: an application server that talks to an in-house video encoding micro-service
Even if that video encoding service only has a single really well designed endpoint, there's STILL coupling between the application server and the video encoding service.
Just because we've replaced a method call with an HTTP request doesn't mean things aren't coupled anymore.
Sure -- you may be able to deploy certain changes to your video encoding service without changing your application service. However, you need to be keenly aware of what changes are compatible with existing application servers and which are not and that adds complexity and cognitive load. Maybe it's worth it in some cases. In many cases, it's not.
