From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Implementing a REST API, Issues with Web Services

I'm looking to add a simple REST API to a couple RT targets.  Right now I'm using a webservice, which is included as part of the rtexe build.  This allows HTTP GET,POST, etc. requests to http://[target IP]:8080/API/[method].

 

The API is not transferring large amounts of data or being called very frequently, it's just used to provide some basic status information about the target in a way which can be accessed with common web-based techniques (versus going through something like the system config API or creating some custom TCP/UDP implementation, etc.).  This is to make it easy to integrate into a custom web panel for some basic status and monitoring of a system, which in this case is composed of several hardware targets.  We do not have access to system link.

 

It works fine initially, however, the webservice eventually stops responding to requests.  I reduced the inactive connection timeout in the embedded webservice conf and this help by extending the amount of time before it becomes non-responsive, but does not solve the problem.

 

Is there some bug with webservices which causes them to hold connections open even once closed and so these are stacking up until the connections limit is reached?

 

Does anyone know of another relatively straight forward way to implement a REST API (server side, not client) outside of webservices in native LabVIEW without resorting to some home grown implementation?



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
0 Kudos
Message 1 of 3
(2,926 Views)

In a similar situation, I had to ensure that the TCP connection is maintained before received or sending any TCP command by implementing an error handling state machine as a sending/receiving method. I don't know if it can solve your problem ( in my case errors 56 and 66 on the server side can occur if no command is received/sent for some time) but you may at least try it or log errors on server side to better understand what's going on.

0 Kudos
Message 2 of 3
(2,883 Views)

This is a somewhat different situation than what I'm facing as I'm not directly using the TCP methods since I'm using a webservice.

 

In case you haven't worked with webservices before in LabVIEW, they allow you to implement VIs as REST API endpoints where the name of the VI is the REST URL.

 

For example if I have a VI called GetVersion.vi, then I may have a URL http://192.168.1.1/API/GetVersion.  So to call that API, rather than use TCP methods, you use HTTP methods (GET, POST, etc.)

 

The issue that I'm having is that my GET request, works for X amount of time and then eventually starts timing out.  Its has something to do with how the NI webserver manages inactive connections, namely the maximum amount of connections it allows and how long it keep inactive connections open.

 

It appears as though it is keeping connections open long enough that I'm maxing out my allowed connections.

 

There isn't any way to log meaningful errors though because the only error I have access to is the timeout coming out of the HTTP method VI.  But I don't have access to the server side as that is buried underneath the mechanisms NI uses in its embedded webserver.  The request is never making it to my REST endpoint VIs (GetVersion in my example), it's somewhere in between where the issue is occurring.



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
0 Kudos
Message 3 of 3
(2,826 Views)