Feature request: API HTTP server #42

Open
opened 2025-11-20 04:19:20 -05:00 by saavagebueno · 6 comments
Owner

Originally created by @qdm12 on GitHub (May 30, 2020).

Originally assigned to: @qdm12 on GitHub.

  1. What's the feature?

Setup a simple HTTP server to serve information and modify settings

  1. Why do you need this feature?

Such that it can be used as an API consumed by the web ui react frontend

  1. Extra information?
Originally created by @qdm12 on GitHub (May 30, 2020). Originally assigned to: @qdm12 on GitHub. 1. What's the feature? Setup a simple HTTP server to serve information and modify settings 2. Why do you need this feature? Such that it can be used as an API consumed by the web ui react frontend 3. Extra information?
saavagebueno added the Complexity: ☣️ Hard to doCategory: Label missing labels 2025-11-20 04:19:20 -05:00
Author
Owner

@fredericrous commented on GitHub (Jan 27, 2021):

I did a quick look online and the Iris framework seems to be a good choice for an API https://github.com/kataras/iris
It is actively maintained, very few issues are opened, there are loads of up to date examples. It looks easy to use/implement. What do you think?

@fredericrous commented on GitHub (Jan 27, 2021): I did a quick look online and the Iris framework seems to be a good choice for an API https://github.com/kataras/iris It is actively maintained, very few issues are opened, there are loads of up to date examples. It looks easy to use/implement. What do you think?
Author
Owner

@qdm12 commented on GitHub (Jan 27, 2021):

Ehh sorry to disappoint, but I'd like to stay away from frameworks. Especially we just need I think a GET, POST and PUT endpoints and call it a day 👍 I'm fine with adding a (good, idiomatic, close to the Go standard library) router like go-chi though.

I'm very used to write HTTP servers in Go, what I can do is lay some foundations and then you can fill it up? But that will probably have to wait until the weekend 😄

@qdm12 commented on GitHub (Jan 27, 2021): Ehh sorry to disappoint, but I'd like to stay away from frameworks. Especially we just need I think a GET, POST and PUT endpoints and call it a day 👍 I'm fine with adding a (good, idiomatic, close to the Go standard library) router like [go-chi](https://github.com/go-chi/chi) though. I'm very used to write HTTP servers in Go, what I can do is lay some foundations and then you can fill it up? But that will probably have to wait until the weekend 😄
Author
Owner

@fredericrous commented on GitHub (Jan 27, 2021):

I was suggesting Iris because it looks super easy and readable from what I read from the section "Simple Handler" of their Readme.md . Also, I believe the go compiler removes unused code so using a framework shouldn't introduce too much heaviness. Anyway, I'm afraid to write an API in Go without structure, that's the main reason I suggested a framework. If you lay down some foundation I sure will be happy to help

@fredericrous commented on GitHub (Jan 27, 2021): I was suggesting Iris because it looks super easy and readable from what I read from the section "Simple Handler" of their Readme.md . Also, I believe the go compiler removes unused code so using a framework shouldn't introduce too much heaviness. Anyway, I'm afraid to write an API in Go without structure, that's the main reason I suggested a framework. If you lay down some foundation I sure will be happy to help
Author
Owner

@qdm12 commented on GitHub (Jan 27, 2021):

Anyway, I'm afraid to write an API in Go without structure

Totally understandable. It took me a while to figure a good structure, and I constantly see oddities in how HTTP servers are implemented / non testable. So it is not trivial indeed 😄

Right now I'm in the middle of solving #136 and will get to the HTTP server right after.

@qdm12 commented on GitHub (Jan 27, 2021): > Anyway, I'm afraid to write an API in Go without structure Totally understandable. It took me a while to figure a good structure, and I constantly see oddities in how HTTP servers are implemented / non testable. So it is not trivial indeed 😄 Right now I'm in the middle of solving #136 and will get to the HTTP server right after.
Author
Owner

@jdevera commented on GitHub (Aug 18, 2024):

I came to suggest a similar feature. In my case, I would only need read support on such API. My goal is to show a summary in a Homepage widget so I can see if everything is fine or if something needs my attention.

Perhaps this could come as a first iteration before considering config changes 👼 .

@jdevera commented on GitHub (Aug 18, 2024): I came to suggest a similar feature. In my case, I would only need read support on such API. My goal is to show a summary in a [Homepage](https://gethomepage.dev/) widget so I can see if everything is fine or if something needs my attention. Perhaps this could come as a first iteration before considering config changes 👼 .
Author
Owner

@Robonau commented on GitHub (Nov 11, 2024):

even a simple json version of what is already on the current page would be fine.
just

[
  {
    "domain": "$domain",
    "owner": "$owner",
    "provider": "$provider",
    "iPVersion": "$iPVersion",
    "updateStatus": "$updateStatus",
    "timeSinceUpdate": "$time in updateStatus in unix time", 
    "currentIPs": "$currentIPs",
    "previousIPs": ["$previousIP","$previousIP"]
  }
]

on /api
would be fine

@Robonau commented on GitHub (Nov 11, 2024): even a simple json version of what is already on the current page would be fine. just ```json [ { "domain": "$domain", "owner": "$owner", "provider": "$provider", "iPVersion": "$iPVersion", "updateStatus": "$updateStatus", "timeSinceUpdate": "$time in updateStatus in unix time", "currentIPs": "$currentIPs", "previousIPs": ["$previousIP","$previousIP"] } ] ``` on /api would be fine
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ddns-updater#42