Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: REST configuration #230

Open
branaway opened this issue Jan 15, 2025 · 9 comments
Open

Feature request: REST configuration #230

branaway opened this issue Jan 15, 2025 · 9 comments

Comments

@branaway
Copy link

Liked it when the tmol worked. Would be really nice to have REST api to reconfigure at runtime to improve the interoperability.

@Gamerboy59
Copy link
Contributor

Gamerboy59 commented Jan 18, 2025

You can just start rpxy using the -w option and all changes to the toml file take effect in less than a second:
-w, --watch Activate dynamic reloading of the config file via continuous monitoring

There's no API endpoint at his moment unfortunately but it'll come to the webui soon.

@junkurihara
Copy link
Owner

junkurihara commented Jan 19, 2025

At this point, i have no plan to implement REST api for dynamic configuration. I had considered that, but i decided not to implement it as a core function of rpxy by the following reason.

  • It can be realized just as follows: Consider a web application implemented to serve a RESTful endpoint modifying rpxy.toml. Also consider the app to be exposed to clients directly or with rpxy, and rpxy runs with the watch option. Then, it works as you need.
  • Violation of my design philosophy. It makes the structure of rpxy complicated to integrate such an 'extra' web server with the rpxy. it is not related to rpxy' reverse proxy core library (rpxy-lib) and should be an external project calling the core (e.g., rpxy-bin). But then, the whole rpxy project has two http servers, the reverse proxy and REST endpoint, separately.
  • Is the following situation acceptable for sys admins?: The configuration file is different from the working state of the reverse proxy. Actually, it is NOT acceptable for me. I believe that if needed, we should implement another rpxy-bin that listens only REST commands (no static reverse proxy setting with file) whie rpxy-lib remains as is.

@junkurihara
Copy link
Owner

junkurihara commented Jan 19, 2025

Maybe the third option of another rpxy-bin dedicated only to REST api would be reasonable. IMHO, worth to consider in detail.

@Gamerboy59
Copy link
Contributor

Maybe the third option of another rpxy-bin dedicated only to REST api would be reasonable. IMHO, worth to consider in detail.

It'll take another few weeks but the next release of rpxy-webui will have an api. It's not restful api yet but I can change it to be rest compliant. Would that be a possible option without having to develop another derivate?

@junkurihara
Copy link
Owner

@Gamerboy59 Sounds nice to enhance rpxy-webui with any type of exposed APIs :-)

The priority to consider the RESTful api inside rpxy(-bin) is not high for me at this point, as explained in my previous comment. So it would be helpful for users that the external helper tool supports it.

@branaway
Copy link
Author

branaway commented Jan 22, 2025

At this point, i have no plan to implement REST api for dynamic configuration. I had considered that, but i decided not to implement it as a core function of rpxy by the following reason.

  • It can be realized just as follows: Consider a web application implemented to serve a RESTful endpoint modifying rpxy.toml. Also consider the app to be exposed to clients directly or with rpxy, and rpxy runs with the watch option. Then, it works as you need.
  • Violation of my design philosophy. It makes the structure of rpxy complicated to integrate such an 'extra' web server with the rpxy. it is not related to rpxy' reverse proxy core library (rpxy-lib) and should be an external project calling the core (e.g., rpxy-bin). But then, the whole rpxy project has two http servers, the reverse proxy and REST endpoint, separately.
  • Is the following situation acceptable for sys admins?: The configuration file is different from the working state of the reverse proxy. Actually, it is NOT acceptable for me. I believe that if needed, we should implement another rpxy-bin that listens only REST commands (no static reverse proxy setting with file) whie rpxy-lib remains as is.

I respectfully disagree on using the toml as the external contact point for any integration work as the best option. I consider the config file as an externalized internal state. The internal routing config should have be exposed for querying and potentially modification via a standard API, REST just being a common choice. My specific case requires frequent adding/enabling specific routes and traffic monitoring, all programmatically.

Additionally I played with the TOML config and sometimes it worked and other times it did not, leaving me the impression that TOML config is not reliable.

Otherwise the proxy worked beautifully.

@branaway
Copy link
Author

@Gamerboy59 Sounds nice to enhance rpxy-webui with any type of exposed APIs :-)

The priority to consider the RESTful api inside rpxy(-bin) is not high for me at this point, as explained in my previous comment. So it would be helpful for users that the external helper tool supports it.

Any reason your project is GPL-3 licensed?

@xkr47
Copy link
Contributor

xkr47 commented Jan 22, 2025

Any reason your project is GPL-3 licensed?

Sounds like an off-topic discussion topic..

@Gamerboy59
Copy link
Contributor

@Gamerboy59 Sounds nice to enhance rpxy-webui with any type of exposed APIs :-)
The priority to consider the RESTful api inside rpxy(-bin) is not high for me at this point, as explained in my previous comment. So it would be helpful for users that the external helper tool supports it.

Any reason your project is GPL-3 licensed?

Basically I want people to make the source available if they fork it and state if and what has been changed.
If there's anything that would stop you from being able to use the software, I could consider changing license but not for the sake of just using another type of license.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants