LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

REST Error Response, Include BODY data

Solved!
Go to solution

I am using the REST Web Service to build an API for some VIs.

 

I want to do the following:

  1. If an error occurs, then change the response such that it is "500" or some non-OK response.
  2. Include in the return data the error information (error code, etc.)

I was able to do number 1 above by calling the Set HTTP Response Code VI.  However, when I do this I am not able to return data (the body is empty).

 

Is there a way to return data while also setting the response code to a non-OK response?

If not, then I have to always return "200-OK", even when errors occur, and include an error data structure in every transaction.

0 Kudos
Message 1 of 4
(2,739 Views)

I spoke with my NI support person and it sounds like this same issue was opened in their issue tracking system back in April 2013.  There may be a solution in the future, but for now this is how the REST service works in LabVIEW.


My work around will be to always return the error cluster; the client will look at the error cluster to determine if there was an error.

 

(Always returning the error cluster is not ideal as it makes for a larger payload and that it breaks the convention of using the HTTP response codes to convey an error.)

 

0 Kudos
Message 2 of 4
(2,602 Views)
Solution
Accepted by topic author darshahlu

To close the loop on this one.  If anyone is interested in tracking this Corrective Action Request, the number is 400778. 

 

A work around to this issue is to use the Stream Output mode rather than the Terminal output mode.  This will allow you to write a response and set the code.  

 

KiraT

0 Kudos
Message 3 of 4
(2,576 Views)

I was just about to give LabVIEW WebServices another chance with the development of production-use API, but it seems like issues such as this one and others are still there, making them clumsy to use and difficult to abide to the recognized REST paradigms.

 

This is quite disappointing in 2018, when the IOT is marching at fast pace towards HTTP-based APIs. NI should step in on this and give WebServices a serious polish.

0 Kudos
Message 4 of 4
(2,257 Views)