Caddy: Feature request: GET text Caddyfile from API

[qdm12]

As far as I know, the built-in API supports:

• Sending a Caddyfile in its text format to the API (POST)
• Sending a Caddyfile in its JSON format to the API (POST)
• Getting the Caddyfile in its JSON format (GET)

Would it be possible to modify/add a GET endpoint to the API to receive the Caddyfile in its human readable (text/Caddyfile) form instead of JSON?

If this is a possibility, feel free to point me to where to modify the code I'll do a pull request for it. If you have a better alternative, I'm happy to hear it as well 👍

Thanks!

[abiosoft]

To clear up the confusion a bit, I'll start by changing the terminology used.

• Sending a Caddyfile config in its text Caddyfile format to the API (POST)
• Sending a Caddyfile config in its JSON format to the API (POST)
• Getting the Caddyfile config in its JSON format (GET)

Caddy is actually not using the Caddyfile directly, but the resulting JSON after converting/adapting the Caddyfile (or other config formats).

There is only one way conversation to JSON via config adapters, the inverse is not supported.
It would not have been a big deal but unlike other formats like YAML or TOML, the Caddyfile is not a straightforward conversion.

Would it be possible to modify/add a GET endpoint to the API to receive the Caddyfile in its human readable (text/Caddyfile) form instead of JSON?

I am tempted to argue that JSON can be human readable too :) but I understand the preference for Caddyfile. However, JSON is recommended for API users and is more suited to dynamic runtime configuration design of Caddy v2.

If I may ask, what is preventing you from working with the JSON config, is it just preference or you are unable to accomplish with JSON what you could with the Caddyfile?

[qdm12]

Ah that makes sense. Do you think there is no way to properly convert the json to a text Caddyfile then? Or it just hasn't been done?

I'm working on an UI to edit the Caddyfile (as a first step) and would like to get the current configuration as a human readable Caddyfile that the user can edit and post back to the api.

If the conversion isn't possible, I might just take alternative routes and forget about the human readable Caddyfile, although I think it's quite UI friendly and I'd be sad to not let the user directly fiddle with it... fiddling with the JSON is way less fun :smile:

[ShadowJonathan]

Do you think there is no way to properly convert the json to a text Caddyfile then?

No, I'm fairly sure caddy v2 wasn't built with this in mind, and only provided limited Caddyfile support for backwards compatibility with existing workflows, but the caddyfile config adapter isnt a 1:1 conversion, and isnt able to do many things that the JSON end result can describe.

For example, if that same JSON end state had some keys/settings/options changed to something that eventually made a change, you'd hypothetically need to drop support for those keys/options when converting to Caddyfile, but what'd happen when the config adapter needs to convert a changed configuration back into JSON? Would it need to overwrite existing configuration? Or ignore it? How'd you think how easy debugging must be that way, if conversion was lossy?

In short; Caddyfile is mostly for compatibility, the recommended way is getting yourself comfortable with the JSON api, and write hand-written config in TOML (as i've heard is fairly intuitive and pleasant to read).

Maybe you can offer a service to "import" caddyfile configuration to display as TOML/JSON instead 🤔.

[abiosoft]

I'm working on an UI to edit the Caddyfile (as a first step) and would like to get the current configuration as a human readable Caddyfile that the user can edit and post back to the api.

If you will only perform updates via Caddyfile, you can simply persist the Caddyfile used and make your UI tool the source of Caddyfile instead of Caddy. That works.

What can be done fairly easily is make Caddy persist the original config file. Caddy already persists the startup config but only the JSON format. That feature can be extended to keep the adapted files as well. Not sure how beneficial that is.

[mholt]

I think it would be best if the tooling that is automating Caddy was responsible for that. There's no reason for Caddy to be concerned about any higher layers that are automating it; that's a bad abstraction. So, just save the Caddyfile input that you POST and make sure no other changes are made to Caddy's configuration between POSTs.

[mholt]

Going to close this, since I don't think the right place to implement such a feature is in Caddy itself, but feel free to continue the discussion; it's an interesting question (but I think the reasons for declining this feature are compelling, especially since the alternative is much simpler).

[qdm12]

Thank you all for your help and suggestions 👍

@abiosoft I'll go with your suggestion for now, where that ui would be the source of truth with a persistent Caddyfile, which sends it to Caddy through the API. That really solves that first step I want to reach 💯

Adding a feature supporting toml for a more complete control of what's possible with the API seems like a nice next step too.

Also for your information, the repository is github.com/qdm12/caddy-ui, feel free to watch releases; I'll make one once it's working properly. Thanks again.

[francislavoie]

Feel free to post that tool to the wiki when you have it working! https://caddy.community/c/wiki/13

[mholt]

(I'd recommend the Showcase category actually: https://caddy.community/c/showcase/12)