Although it doesn't directly go against what you're saying, many Unix daemons have supported HUP signals for decades which can achieve the same outcome. No need to configure via API, just change the configuration on disk and send HUP.

I suppose arguably that becomes a bit trickier for containers, so perhaps that's why you'd want to configure via an API?

Nginx can reload configs on HUPs -- https://docs.nginx.com/nginx/admin-guide/basic-functionality...

To me this is identical - mutable state is mutable state, whether it starts on disk first makes no difference.

There is a slight difference to me as having another service run (the API) is an additional attack vector to worry about from a security perspective.

I would also say it's easier to enforce good "IaC hygiene" when the configs are managed via configuration files. They can go through a code review process, deployed via existing config management systems etc.

Any half decent containerized setup should support zero-downtime deploys. Usually it involves bringing up new containers and signaling the existing containers to begin draining connections.

For most workloads it should be entirely possible to deploy a new stateless config and not need to resort to using mutable state for critical infrastructure.

If you have long-lived, stateful connections (perhaps for live streams) then I can see why re-configuring in place would be desirable, but in my experience that's pretty rare.

Neither Apache nor nginx require a restart to add php support, and neither will lose requests under normal operation. They will however parse the complete config on a reload operation. On huge configurations this is noticeable.