If you query the root HTTP path of the API, it will show you all HTTP paths available.
Unfortunately, BIG-IQ does not implement next HTTP paths for all paths, so the following does not work in BIG-IQ.
See the documentation section for a full list of HTTP paths.
A BIG-IQ device provides a subset of the BIG-IP functionality, plus functionality that is specific to BIG-IQ.
For example, you can list the self IPs in both BIG-IQ and BIG-IP using the following tmsh command:
This means that the majority of the HTTP path you use in the BIG-IP API for the device itself will also work with BIG-IQ.
Those HTTP paths will start with /mgmt/tm/.
HTTP paths to work with BIG-IQ functionalities start with /mgmt/cm/.
HTTP paths for functionality that is specific to the iControl REST API start with /mgmt/shared/
The API is similar to tmsh commands.
However, BIG-IQ only has tmsh commands that are specific to the BIG-IQ itself.
If you want to list all virtual servers using the API, you do:
BIG-IQ is a very new product compared with BIG-IP, however, it had many major changes since it was created.
The adc-core name is the same as LTM, and I assume it is a legacy from the time BIG-IQ had separated products.
Instead of using the object name as the key to get the object, BIG-IQ API uses IDs.
If you want to list a single virtual server using the API you do:
This means you need to know the ID, or you have to get the ID before.
The SDK has a function called “id” to help with that.
BIG-IQ API also requires you to provide a link to an object in some cases.
For example, if you create a virtual server, you have to provide a link to device object.
The link is sent as part of the payload and means the virtual server will be linked to that device.
The SDK has a function called “link” to help with that.