Plans for JSON API queries?

[jlesquembre (José Luis Lafuente)]

Hi,
first, thank you to the Caddy developers for their work, I discovered it recently, and looks great!

I think it would be useful to be able to do some queries using the JSON API, questions like, what is the name of the server listening on port 8080? Or, what route matches a request to test.com/api?

Do you think it would be useful? Are there some plans for that?

My use case is that I want to add a new route with the API, but I don’t know if there is already a server listening on the port I want to use. Depending on if there is one or not, I want to create a new server or a route on an existing server.

Right now I see 2 options, one is to do a request to get the whole configuration and parse it myself. The other one is to try to create a new server on the port I’m interested in and if there is an error I could extract the server name from the error, e.g.:

curl -X POST \
     -H "Content-Type: application/json" \
     -d '{"listen" :[":8081"]}' \
     "http://localhost:2020/config/apps/http/servers/myserver"
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Date: Tue, 08 Sep 2020 21:40:04 GMT
Content-Length: 182
Connection: close

{"error":"loading new config: loading http app module: http: invalid configuration: server myserver: listener address repeated: tcp/:8081 (already claimed by server 'myserver')"}

But both solutions seem a bit hacky to me, I’d prefer a more direct way to do those queries.

[francislavoie]

@jlesquembre

Right now I see 2 options, one is to do a request to get the whole configuration and parse it myself.

This is what you should do. You can use jq to make queries against the JSON config yourself.

https://stedolan.github.io/jq/

This isn’t the sort of thing that belongs in Caddy, there’s not really any benefit. Any solution would be too app-specific and it would take a lot of effort to maintain. Our time is better spent making the server features better and fixing bugs.

[jlesquembre (José Luis Lafuente)]

Thanks for your answer.
The only point I have against parsing the configuration in my application, is that I’m basically duplicating the Caddy parsing logic in my code. But on the other hand, I understand that adding a query API could take a lot of effort and you prefer to spend your time in other tasks.

Thanks again for Caddy, its API is a really powerful feature.

[matt (Matt Holt)]

Great question though! The Caddy admin API is extensible, so plugins can add their own endpoints to it.

I feel like this could work. Assuming a handler can access the current Caddy configuration (I might need to add a simple function to return it, someone would have to check), it should just be a matter of implementing that search/traversal logic as a single plugin that can serve any clients, rather than having each client have to implement it.

But again, I think either solution is good. The best one in the immediate-term that doesn’t involve extending or modifying Caddy is to just parse it yourself on the client-side.