From ZVR 5.0 update 3 release notes users may have seen an update to ZVR API which was a security improvement, which may cause some existing scripts now not to function on ZVR 5.0 update 3. This is down to the accept headers set in the scripts. This is a quick and easy fix, first we will explain how the API works and then how to resolve this at the end.
Some Basic facts:
Our API supports two formats(Content-types) in the response – XML, JSON,
The response format can be controlled in the request headers by using “Accept” header with desired content type.
When user does not supply an 'Accept' header in the request he leaves the decision to the server on which format to use in the response Body,
When user does not supply an 'Accept' header it is in his / her responsibility to check the response format.
Since 5.0 Update 3, the response format in case no 'Accept' header was given in the request is JSON (application/json).
Before – it was set by request content type
The change is due to a security feature we added to the REST API.
The cause for a script failure:
When XML content type is returned there is another level of naming, the top level, for example retrieving a VPG list of all the VPGs in a site will yield the attached responses (See image)
As you can see in the JSON format there in no name for the top level object (ArrayOfVpgApi) where the XML response there is, now in pre-5.0U3 versions, requests with content type “application/xml” or “text/xml” would yield a xml response, while in 5.0U3 the request Content type is ignored and only request “Accept” header will determine the response format.
So a simple fix is to supply "accept header" of the script to ensure your scripts stay functioning within your environment, this is a quick and easy fix which should prevent users scripts from being disrupted / not used.