Instead of focusing on a mechanism (port binding), the focus should be on containerization, and the verbiage should also allow for things like UNIX-domain (file) sockets for the exposed connection. If anything, UNIX-domain sockets are superior to plain port binding because they're more secure on several axes:
Finer-grained access control, following the UNIX permissions model
No chance of a misconfiguration exposing the raw port to the outside world
Limits the attack surface for multiple users on a shared system
Additionally, in my own experience it makes things a lot easier to configure, since you don't have to run anything that keeps track of a service-port mapping, and it's way less likely to make mistakes with e.g. configuring multiple services on the same port or reverse proxying to the wrong one. You can also make better use of systemd to only launch the underlying service when the socket is needed by the fronting server, which can save on resources when managing several services which only run on rare occasion.
Instead of focusing on a mechanism (port binding), the focus should be on containerization, and the verbiage should also allow for things like UNIX-domain (file) sockets for the exposed connection. If anything, UNIX-domain sockets are superior to plain port binding because they're more secure on several axes:
Additionally, in my own experience it makes things a lot easier to configure, since you don't have to run anything that keeps track of a service-port mapping, and it's way less likely to make mistakes with e.g. configuring multiple services on the same port or reverse proxying to the wrong one. You can also make better use of systemd to only launch the underlying service when the socket is needed by the fronting server, which can save on resources when managing several services which only run on rare occasion.