did version 5 remove the returned task uris?

[BradV]

I recently upgraded our oneview from 4.2 to 5.0.  I'm also working on getting a oneview instance at each geographic location.  So, I just added a new instance to one of our locations.  I went to our original oneview through the rest api and deleted all of the servers from the geographic location of the new oneview instance.  I noticed there was no deletion task uri returned, nor anything.  I then started adding them to the new instance and noticed no taskuri was returned from the post command to add them.   Is this the new design, or a bug? 

Another example.  I am getting ready to connect the new OneView instance to our AD.  I used this in version 4 and got a returned task.  Under version 5, I get nothing in return, even though it works:

ROOTB=$(curl --insecure https://our.org/ca_certs/base64/pkiroot.cer 2>/dev/null | awk 'NF {sub(/\r/,""); printf "%s\\n",$0}' 2>/dev/null)
ROOTB=${ROOTB%'\n'}
ROOTCA=$(curl --insecure \
   --header "content-type: application/json" \
   --header "accept: application/json" \
   --header "X-API-Version: ${currentVersion}" \
   --header "auth: ${sessionID}" \
   --data '{ "members": [{ "type": "CertficateAuthorityInfo", "certificateDetails":{ "base64Data":"'"${ROOTB}"'", "aliasName": "Our_Org", "type": "CertficateDetailV2"}}], "type": "CertificateAuthorityInfoCollection" }' \
   --request POST ${OneView}/rest/certificates/ca | jq -r '.uri')

[ChrisLynch]

In our REST API reference documenting HTTP Status Codes, an HTTP 202 reply will return an HTTP header called Location.  That will contain the taskUri string value.  Your code when issuing a POST, PUT, PATCh or DELETE should examine the HTTP response code.  If HTTP 202 is returned, to begin looking if there is a response body (which may still happen for a few resources even though they should be returning the Location HTTP header), then the HTTP Location header.  The other status code would be HTTP 201.  Taking a look at 5.00, adding a trusted certificate to the appliance store does return an async task.

We also document changes in the REST API, which you can get from the What's New section of the REST API Reference Guide.

[BhaskarV · Accepted solution]

Thanks @ChrisLynch 

You are right.
Prior to version 5.00, the task resource was being returned as part of the response body.
See here:
https://techlibrary.hpe.com/docs/enterprise/servers/oneview4.2/cic-api/en/index.html#rest/certificates/ca

However, the REST API specification expects us to return the task in the response header and hence to stay compliant to the spec, this was changed in 5.00
Mentioned here:
https://techlibrary.hpe.com/docs/enterprise/servers/oneview5.0/cic-api/en/index.html#rest/certificates/ca as

HTTP/1.1 202 Accepted with Task URI in the Location Header

BradV

You can specify X-API-Version in the header to 1000 so you can continue to stay with the previous behavior, i.e your script will continue to work. On a 5.00 appliance, for backward compatibility reasons, the older API version 1000 continues to be supported.
You can also modify your script to extract the task from the response header if you want to stay current.

Regards
Bhaskar

[BradV]

Thanks guys.  I'm going to have to revise my scripts.