network_security_rules
access_control_policies
availability_zones
batch
blackouts
categories
clusters
reports
directory_service
hosts
idempotence_identifiers
identity_providers
images
network_function_chains
alerts
ngt_policies
permissions
projects
protection_rules
recovery_plan_jobs
recovery_plans
roles
subnets
tasks
user_groups
users
routing_policies
vms
Models
Powered by Stoplight

INTRODUCTION

Representational state transfer ( REST ) Application Programming Interface (API) 3.0 is based on an intentful API philosophy. According to the intentful API philosophy the machine should handle the programming instead of the user enabling the datacenter administrator able to focus on the other tasks. You need to specify the end state of an entity and the system will compile and execute a series of steps to achieve the defined end state of the entity. The progress to achieve the desired state is tracked through waits and events. This approach is similar to the Google Kubernetes standard.

All the entities and the list of entities follow a homogenous specification format resulting in ease of programming despite different entities being involved. Also, this enables the user to get familiar with the APIs quickly.

Intentful APIs reduces the number of action verbs required to achieve the desired state of an entity. Most of the changes can be achieved by defining the desired state of an entity rather than through a series of action verbs.

TERMINOLOGY

  • Entity - An object that can be managed through an API.
  • Kind - Represents the type of entity. For example, VM or, alerts.
  • Resource Kind - An entity that represents a physical or virtual infrastructure resource. For example, VM or, an app.
  • Helper Kind - An entity that is not an infrastructure resource but represents the entity that is used along with the infrastructure resources. For example, alert, event, or status.
  • Basic Resource Kind - An entity type that is a primary resource. For example, VM.
  • Related Resource Kind - An entity type that is automatically defined by the system and is related to the basic Kind entities. For example, vm_snapshot.
  • Type - Represents sub-categories or sub-objects of the top-level resource types. For example, reference.
  • Resource Limit - An entity type that represents a quota of resources of different types.
  • Snapshot - Represents the state of resources and policies of an entity at a particular point of time.
  • Backup - An automatically created aggregation object that collects all the snapshots for the same object within the same resource pool.
  • Profile - A profile is a set of resources and policy specifications that can be directly applied to an entity.
  • Template - A template is a specification by using which valid entities can be generated by providing input parameters.
  • Spec - A section in the request json which represents an entity that expresses the desired state of the entity.
  • Status - A section in the json representation of an entity that expresses the current state of the entity.

RULES

  • The metadata section has fields that relate to all kinds of entities and can be updated instantly by the system.
  • The spec section cannot be updated after initialization by the system without a user or automation intervention.
  • The status section has a copy of the currently enforced version of the spec section and other fields that are managed or updated automatically by the system. Few fields in the status section can be updated by the user as well.
  • The parent_reference field is mandatory for snapshot and backup entities and is present in the normal entities, if the entities are created with the parent_reference field populated (clone or restore).
  • Any field that represents a defined type has the type name as a suffix. For example, backup_factory and vm_reference.

Nutanix API versions – What are they and what does each one do?