I've been working on a deployment tool for OVF/OVA's to vSphere/vCenter and decided to take the relativeishly new (vSphere 6.5) path of using vSphere REST APIs vs shudder the SOAP path. At first look it seemed quite nice: A easy to understand RESTful interface that can easily be accessed from well understood Node.js libraries.
...well, I'm here to tell you that unless you're planning on doing something dead simple, you're still stuck with SOAP.
A couple of the major roadblocks I ran into:
- The OVF deploy API's
additional_parametersappears to simply not work. Passing in malformed parameters correctly yields an error while sending them correctly results in the server simply ignoring them. This works in SOAP of course.
- There does not seem to be any way to establish connections between available resources. For example, want to know what network(s) are available for a given host? Too bad. Again, easy in SOAP.
Another odd quirk:
Similar to the SOAP API, with REST when uploading a library item such as a .vmdk, while
PUTing the file, you must also periodically call another REST call to tell the server how much (percent) is uploaded of said file. The hell? Why the server isn't just using the
Content-Length header and tracking progress I do not know.
While it's cool that REST is being added, it's clearly a wrapper around the existing SOAP concepts (and maybe the APIs themselves) and it's even more clear that it's half baked. Why this is the case in 2018 when REST is in all likelyhood on the way out while GraphQL is on the way in, I don't know.