The configuration file allows to reconfigure at once in an atomic manner. The configuration is also verified before reconfiguring and can be aborted if it's not runnable.
HTTP offers none of this. No atomicity and no consistency of the full configuration. Want to edit a service or maybe alter some hosts? Better hope it's already setup as expected before editing and you're doing all the right calls in the right order and they all succeed. You will have to write the hell of a state machine to ensure to get to the expected state.
The only sane use case for live-changes is enabling/disabling a server, which is necessary to perform rolling maintenance or blue-green deployment.
The HAProxy Data Plane API performs a validation check: it sends the -c flag to the HAProxy process before reloading to make sure that it is a valid configuration. If the configuration is invalid, the changes will not take effect and you will see errors in your console or log. With transactions, it's not quite stateless (as HTTP is). Transactions provide a way to make multiple changes and apply them with a single commit. The main benefit of an API is towards program-ability (is that a word?), in which configuring HAProxy can be controlled by "control plane" software, slick looking UIs, tools like Ansible, etc. in an automated way. You can also generate client-side code from the API, such as for Go/Python/[insert language] coding. It goes beyond the use case of "I'm a human who wants to control HAProxy manually or with templates".
HTTP offers none of this. No atomicity and no consistency of the full configuration. Want to edit a service or maybe alter some hosts? Better hope it's already setup as expected before editing and you're doing all the right calls in the right order and they all succeed. You will have to write the hell of a state machine to ensure to get to the expected state.
The only sane use case for live-changes is enabling/disabling a server, which is necessary to perform rolling maintenance or blue-green deployment.