vCenter Orchestrator HTTP API: POST Request Error 400 1032

[ccurry]

I am trying to start a workflow via a POST request to the vCenter Orchestrator API. When I run the same workflow with a GET request, there are no issues and I get the following output in the localhost_access_log.current_date.txt:

[src_ip_address]- - [13/Oct/2015:04:46:00 +0000] "GET /vco/api/workflows/af83cf34-6a00-45b5-946e-0d44ece508bb/executions/ HTTP/1.1" 200 272

However, when I run a POST with the following parameters:

restMethod: POST

restEndpoint: https://[dest_ip_address]:8281

restPath: /vco/api/workflows/af83cf34-6a00-45b5-946e-0d44ece508bb/executions/

user: [username]

content: {"parameters":[{"name":"name1","type":"string","value":{"string":{"value":"value1"}},"scope":"local"}]}

contentType: application/json

accept: application/json

I receive the following error in localhost_access_log.current_date.txt:

[src_ip_address]- - [13/Oct/2015:03:53:39 +0000] "POST /vco/api/workflows/af83cf34-6a00-45b5-946e-0d44ece508bb/executions/ HTTP/1.1" 400 1032

And the output on the client side:

{Success=no, ResponseHeader={null=HTTP/1.1 400 Bad Request, Server=Apache-Coyote/1.1, Content-Length=1032, Content-Language=en, Connection=close, Date-Tue, 13 Oct 2015 Message=Bad Request, ReasonPhrase=Bad Request, StatusCode=400}

I am running vCenter Orchestrator 5.5. There is no output to the server.log file. I haven't had any luck researching the '400 1032' error number. [dest_ip_address] is HTTPS. Can anyone help clear this up?

[iiliev]

There is no such thing as error '400 1032'. 400 is HTTP status code (Bad Request) and 1032 is the size of the response body.

Which REST client do you use to invoke these REST API calls? Some browser-based client? Or curl? Or something else?

Error 400 usually means that request body is not properly formatted. In your case, it probably means the client you use doesn't handle double quotes correctly.

Fixing this again depends on the REST client you use. For example, if you use curl and pass the request body on shell command line, you can try to pass request body as a file - just put the JSON request body in somefile.json and invoke curl with parameter -d @somefile.json  instead of -d 'request body string'

[ccurry]

I agree with the formatting hypothesis. When debugging in cURL, I'm using the following command:

curl -ku [username]:[password -H "Testing VCO" -H "Content-Type:application/json" -d "{}" https://[dest_ip_address]:8281/vco/api/workflows/af83cf34-6a00-45b5-946e-0d44ece508bb/executions/ -X POST

This is read by the destination, and returns code 202. On my Orchestrator client, I can see the workflow has run, but failed (due to the empty parameters). At this point it seems safe to assume the formatting of the parameters is the issue. The current format I'm using is:

curl -ku [username]:[password -H "Testing VCO" -H "Content-Type:application/json" -d "{"parameters":[{"value": {"string":{ "value":"value1"}},"type": "string","name": "name1","scope": "local"}]}" https://[dest_ip_address]:8281/vco/api/workflows/af83cf34-6a00-45b5-946e-0d44ece508bb/executions/ -X POST

This returns code 400. Are there any glaring issues with my formatting method?

[iiliev · Accepted solution]

The command line below seems to work for me when run from the Windows cmd terminal:

curl -ikv -u username:password -H "Accept: application/json" -H "Content-Type: application/json" -d "{\"parameters\":[{\"value\":{\"string\":{\"value\":\"value1\"}},\"type\":\"string\",\"name\":\"name1\",\"scope\":\"local\"}]}" -X POST https://ip_address:8281/vco/api/workflows/af83cf34-6a00-45b5-946e-0d44ece508bb/executions

Note that double quotes inside the request body are escaped with backslash character \

[ccurry]

This did the trick. Turns out the method I was using to structure the JSON parameters was hitting issues with special characters, most likely double quotes. Calling a cURL method instead got the request working.