Up until vSphere 8.0, there were two primary sets of vSphere APIs:
Note: Technically, there are other vCenter Server API endpoints including vSAN, Storage Policy Based Management (SPBM), etc. but for the purposes of this article, we are focusing on the core vCenter Server functionality.
The vSphere Web Services API was available starting with the Virtual Infrastructure (VI) 2.x release back in 2007. To date, the vSphere Web Services API supports the latest vSphere 8.x release and still also has full backwards compatibility going all the way back to Virtual Center 2.x!
As you can imagine, the vSphere Web Services API covers an extremely large amount of functionality over the past 16 years since its introduction and it continues to be widely used by almost all customers either directly or indirectly through the various vSphere SDKs including PowerCLI, pyvmomi (vSphere SDK for Python), govmomi (vSphere SDK for Go), Terraform Provider for vSphere to just name a few. In addition, we also have many 2nd party solutions from VMware and thousands of 3rd party offerings from our broader ecosystem of partners that provide integrations with the vSphere platform, all consuming the vSphere Web Services API!
In 2016, vSphere 6.0 was released and it also introduced a new vSphere REST API endpoint called the vSphere Automation API, but its functionality was limited to just two new features that was added in that release: vSphere Tags and vSphere Content Library. While the initial release of the vSphere Automation API was limited, with each subsequent vSphere release, new vSphere features have been introduced and would only be available from an automation standpoint when using the vSphere Automation APIs.
Both the vSphere Web Services and vSphere Automation API are incredible powerful and while there are some overlap, both are necessary.
With all that background, lets now turn our attention to the topic of this blog post ... is there a vSphere REST API for X, where X is specific vSphere task or configuration?
This is probably one of the most common question that I have seen in recent months, especially with the simplicity of a RESTful or REST-like API that standardizes on JSON as its payload format.
To help bridge this gap, a new VI/JSON API has been introduced as part of the vSphere 8.0 Update 1 release, which provides a REST-like API experience, that includes full parity with the existing vSphere Web Services API.
For users that prefer to work with a JSON-based API whether that is using cURL, Postman or natively within your scripting or programming language, you can now automate every aspect of the existing vSphere Web Services API with this new VI/JSON API!
If you are interested in getting started, here are a few useful resources that have been published by the vSphere API team on using the new VI/JSON API:
- Automating vSphere Workflows with VI/JSON
- Integrating VI/JSON in pyVmomi scripts
- vSphere management with Java and VI/JSON APIs
You can also find the new VI/JSON API reference HERE, which you can easily search for a particular operation and if you are familiar with the existing vSphere SOAP API, then this should feel very familiar. Since the new VI/JSON API is still based on the same object model that the vSphere Web Services API uses, it is also helpful to familiarize yourself with how the vSphere Web Services API is organized and here are a few articles (HERE, HERE and HERE) that I have written about in the past that may be a useful.
Lastly, while playing with the new VI/JSON API, I found that I could leverage the vSphere Automation (REST) API to quickly lookup a vSphere Managed Object Reference (MoRef) ID, which I can then perform an operation using the VI/JSON API. To demonstrate the use of both the vSphere Automation API and VI/JSON API, here are a few example scripts that exercises some of the popular use cases that I frequently get asked about, which are not possible when using just the vSphere Automation API: