Hi,
I know that the RemoteInterface relies on XML-RPC. I tried to investigate how complicated it would be to port it to REST and did come to e definite conclusion.
Should I fork the remote interface and port it to REST?
Or is it maybe possible to make some magic conversion from XML-RPC to REST?
Is the approach even at all possible?
Regards,
Markus
The question i have is: Why?
i mean, what is it that you want to improve or what use case do you want to solve?
There are other “Remote Procedure Call” tech out there. Like JSON-RPC or gRPC.
i also have implemented a Remote Server that is running and reacts on HTTP GET requests and give me some information, but calling a http api or doing RPC calls are two different use cases.
I would like to provide libraries as a service and share them on API management platforms.
While there are platforms that allow some RPC variants, REST is always supported.
Maybe gRPC woud be better. Most API platform support or will support gRPC. And those who does not at least offer adaptors (for cost on latency).
Do you know, if there are attempts for ports of Remote Interface/Server to gRPC?
Are we talking with respect to the overall RobotFramework ecosystem with REST (for remote library) support in:
If the whole ecosystem, that would be significant work, and adoption besides yourself would require the RF team to accept your PRs. But if you just needed to serve some of RF’s libraries (native or 3rd party ones) over REST or other RPC, you could extend the applicable remote server implementations (python, java, .NET, etc.) to offer an alternate interface to run the keywords, which is a lot easier to do. Then using said patched servers you can run compatible RF libraries that are in the same language as the patched server, over REST/RPC.
Actually the Remote Library is part if the robot package, but has no connection to the core.
You can build your own completely independent from core project!
Still i a not sure what problem you try to solve.
XML-RPC is available in nearly all language implementations. Often without any third party dependancies.
It is possible to use it with micropython, c, js, groovy , etc.
It is not a language problem but an infrastructure challenge.
If I want to offer a “library hub” current platforms I have i mind offer REST as protocol.
But I think gRPC is good.
FYI, for what work has been done for gRPC and REST, maybe there’s more but a quick search only comes up with these: