I've found rclone to be a powerful tool, especially its RC API. I want to use rclone as a microservice controlled by another service in my system. To achieve this, I need a clear and well-defined API for interaction.
However, from what I can tell, rclone's current API seems tailored for internal use, and it doesn't appear to be documented as an OpenAPI specification or similar format.
Given this, I see two possible approaches:
Define the existing RC API using an OpenAPI spec and generate client libraries for other languages (e.g., Kotlin).
Create a new interface for remote-controlling rclone, perhaps using gRPC.
Has anyone attempted to use rclone in this way before?
P.S. To be honest, I’ve already attempted the first approach, but unfortunately, it wasn’t very successful.
P.P.S. If the maintainers are open to it, I'd like to proceed with the second approach. I just wanted to hear your thoughts first.
The API is all internally documented in code and I did have the idea in the past that rclone could automatically generate an OpenAPI spec itself. It would need a bit more internal specification of what exactly the inputs and outputs were. These are defined in Go structs which are typed.
At a very basic level the API PUTs a JSON blob and receives a JSON blob in return and that isn't hard to implement in any language.
If we made a gRPC API it would be a shim over the existing one I expect.
The API is all internally documented in code and I did have the idea in the past that rclone could automatically generate an OpenAPI spec itself. It would need a bit more internal specification of what exactly the inputs and outputs were. These are defined in Go structs which are typed.
Am I right to understand that you support the idea of generating OpenAPI spec from code? I mean, it would take some effort, but it's doable and as a result, we can have language independent API contract, which also resolves my issue.
At a very basic level the API PUTs a JSON blob and receives a JSON blob in return and that isn't hard to implement in any language.
For sure, but I don't think that any developer should spend his time on it in case it could be done at least semi-automatically. Do you agree?
If we made a gRPC API it would be a shim over the existing one I expect.
Makes sense, I mean in this case it's code duplication without much profit.