08-25-2025 09:38 AM
I basically want to add an API to my LabVIEW built executable so that it can be programmatically controlled by some external caller.
Right now I'm looking at adding a REST API via LabVIEW webservices functionality, and that isn't too bad. It's pretty straightforward, standardized, and support security features such as authenticating API calls and encryption via over HTTPS. This executable is also being used in an environment where there are a number of webservice-like tools which already provide a REST API themselves which will likely have to be interacted with down the road, so it makes sense in my mind to maintain that as the go-to for the implementation.
All that said, what are some other options and their pros/cons?
VI server? Custom TCP listener? MQTT? RPC?
I want to explore all options.
08-25-2025 11:55 AM
I think the best way to narrow this down is to ask "Who is your customer?" first, followed by the level of effort you want to go to second.
I ask because using VI server may involve the least amount of effort to use with your program, but also likely much less likely to be wanted to be used by a large audience.
08-25-2025 12:23 PM
Agreed. Generally leaning away from VI server. Much of this will be used between different LV built EXEs, however in some cases, non-LV systems, users, etc. will be interacting with it so something that is agnostic to LV will be needed and I don't like the idea of having a split API which implements functionality in VI server for case A and something more standardized for Case B.
There also isn't, to my knowledge, good options for securing the API in the VI server case since it really just has access control lists but no real authentication/encryption.
08-25-2025 01:29 PM
Given that, I would lean towards recommending the REST API approach so long as its capabilities meet your requirements. It's commonly used and well understood, and most non-LV programmers would see no issue with it in most cases.
However, a REST API has some aspects that make it easy to work with but also could be limiting depending on your intentions.
I don't know how much you have looked into it, but as an example, a REST API must be "stateless", meaning that each request must contain all of the information necessary to be understood by the server, rather than be dependent on the server remembering prior requests in some way.
A REST API is also not really an option if you want to do any sort of passive streaming of data to a client, since it can only send information in reply to a request, so you'd have to ask that clients send a nonstop series of requests to your server to mimic this.
08-25-2025 01:30 PM
The "launch" capability implies some program is going to run with user privileges on the machine running the LabVIEW exe, but separate from that exe. If that statement is correct, it affects the rest of the design. I would think about this kind of bootstrapping early as I have seen it get out of hand.
In the past I've used a separate service to manage starting, stopping, and updating the actual applications.