We are writing a REST call in web service for a 3rd party to access some data. 

I am using $webinfo("status") to return 201 or 204 for successes and 400 for failures. The 3rd party is complaining that:-

1. The status is showing twice in the response line. 
2. There is no indication of a reason for failure. 

I have tried using $webinfo("statusreason") to both change the duplication and/or return the reasons for failure, but the documentation indicates it's only returned if the status is 200. 

Is there any way to fit the USP output to the 3rd party's perceived 'standard' for REST services (i.e. status only once in the response line, followed by the reason for failure in case of a failure?   

Regards, 

Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB
------------------------------

I had a quick look, and I cannot really see what the 3rd party is describing.

1. What is the response line and where is it displayed?
2. Did you fill $webinfo("OUTPUT") with the reason for failure?

I have found an old example and there the status is set with $webinfo("status") and any additional info is passed with $webinfo("OUTPUT"). In the case of status 204 there is nothing returned, since the status should be self-explanatory: No Content.

I hope this helps.

Regards,

When I run it in test environment with a URL which will fail due to a lack of input data, and the error status 400 is returned, 

$webinfo("STATUS") = 400
$webinfo("statusreason") = "No hubspot object id passed in"
$webinfo("output") = "{"error":1,"error_details":"No hubspot object id passed in"}"

 The response via SoapUI (my go to REST/SOAP tester) this gives the following output.

HTTP/1.1 400 400
Cache-Control=no-cache
Content-Type=text/html
Expires=Thu, 01 Jan 1970 00:00:00 GMT
Server=Microsoft-IIS/10.0
Date=Wed, 05 Jul 2023 13:39:37 GMT
Content-Length=11

Bad Request

Although spotting that that message was proxied through IIS (using the isapi_redirect) from the machine in our DMZ, I tried it again in the local environment and now I get this, so it appears the problem is that the IIS is not passing the output directly. 

HTTP/1.1 400 
Cache-Control=no-cache
Date=Wed, 05 Jul 2023 13:49:06 GMT
Expires=Thu, 01 Jan 1970 00:00:00 GMT
Content-Type=application/json
Content-Length=60
Connection=close

{"error":1,"error_details":"No hubspot object id passed in"}

We are REALLY unlikely to get anyone who lets us run services direct to the tomcat on their production machine, so I will check if there's something in the IIS isapi_redirect setup which allows the correct data to be passed out. 

Regards, 

Iain