GET

In this section we will see how to make a GET request to the Mobility Conductor. GET method is used to get the configuration data for an object/s or container/s.

• Once the authentication token (UIDARUBA) is obtained using login endpoint, one can start fetching data from the system datastore using various API endpoints.

Syntax for GET request using cURL:

curl --insecure -b "aruba-cookie" -X GET -i 'https://<mcr-ip>:/4343/v1/configuration/object/int_vlan?config_path=<config-node>&UIDARUBA=<session-token>'

📘

Note

--insecure or -k option can be used with the cURL command if the certificate of the Mobility Conductor cannot be validated
-b is used to read the cookie from "aruba-cookie" file
-i is used to include protocol headers in the output

Description of user-specific values used in the cURL example

GET API Request

Request URL:
https://:4343/v1/configuration/object/

Request Query Params:
config_path:
UIDARUBA:

Request Headers:
Content-Type: application/json
Accept: application/json
Cookie: SESSION=

Request Payload:
None

Sample response for a GET request to fetch Interface VLANs:

{
  "_data": {
    "int_vlan":
      {
        "id": 198,
        "int_vlan_ip": {
          "ipaddr": "111.1.1.1",
          "ipparams": "ipaddrmask",
          "ipmask": "255.0.0.0"
        },
        "int_vlan_routing": {
          "_present": true,
          "_flags": {
            "default": true
          }
        },
        "int_vlan_ndra_hlimit": {
          "_flags": {
            "default": true
          },
          "value": 64
        },
        "int_vlan_ndra_interval": {
          "_flags": {
            "default": true
          },
          "value": 600
        },
        "int_vlan_ndra_ltime": {
          "_flags": {
            "default": true
          },
          "value": 1800
        },
        "int_vlan_ndra_mtu": {
          "_flags": {
            "default": true
          },
          "value": 1500
        },
        "int_vlan_nd_reachtime": {
          "_flags": {
            "default": true
          },
          "value": 0
        },
        "int_vlan_nd_rtrans_time": {
          "_flags": {
            "default": true
          },
          "value": 0
        },
        "int_vlan_mtu": {
          "_flags": {
            "default": true
          },
          "value": 1400
        },
        "int_vlan_suppress_arp": {
          "_present": true,
          "_flags": {
            "default": true
          }
        },
        "int_vlan_ip_ospf_cost": {
          "_flags": {
            "default": true
          },
          "value": 1
        },
        "int_vlan_ip_ospf_dead_interval": {
          "_flags": {
            "default": true
          },
          "value": 40
        },
        "int_vlan_ip_ospf_hello_interval": {
          "_flags": {
            "default": true
          },
          "value": 10
        },
        "int_vlan_ip_ospf_prior": {
          "_flags": {
            "default": true
          },
          "value": 1
        },
        "int_vlan_ip_ospf_retransmit_int": {
          "_flags": {
            "default": true
          },
          "value": 5
        },
        "int_vlan_ip_ospf_transmit_delay": {
          "_flags": {
            "default": true
          },
          "value": 1
        }
      }
    }
  }

Understanding the response

• "_data" specifies the data or configuration elements from the Mobility Conductor.

• "_flags": This is a special field in each object/sub-obj level which specifies details about the data. If none of these flag types are specified (flags are empty), then this structure may be missing. The various values possible inside are:

  • "inherited": Specifies that this configuration element has been inherited from the hierarchy above. It means that the configuration present here has been configured on a node above this and not at this node.
  • "readonly": Species that this configuration element is readonly -- it can't be edited. It can only be deleted.
  • "undeletable": Specifies that this configuration element can't be deleted -- it can however be edited.
  • "pending": Specifies that this configuration hasn't been saved in flash and has not yet been pushed to apps.
  • "default": Specifies that the configuration is part of factory default configuration or is generated as default by the system.
  • "system": Specifies that the configuration is system generated.

GET Modifiers

Response from the system for a GET request can be further modified using the GET Modifiers. There are various modifiers you can use to get a subset of data according to your need. These modifiers are used as query params for the API request.
Different types of modifiers that can be applied to the response of a GET request are as follows:
Basic Filters (Key/Value Filters): There are two types of basic filters:

• Object Filter: This modifier limits the endpoints or sub_endpoints that should be present in the response
• Data Filter: This modifier is used to filter out the configuration elements configured on a system.

Data-Type Filters: This modifier is used to provide a subset of data for an endpoint for the type of configuration specified

Sort: This modifier is used to sort the data received from the system

Paginate: This modifier is used to tell the system to provide the amount of data required or specify the blocks of data require

Count: This modifier is used to count the data-fields for any API endpoint or sub-endpoints/sub-parameters for an API endpoint

More information on how to use the above modifiers with the GET request can be found in the ArubaOS REST API Guide given below.

👍

Available Endpoints

To view the list of all the available endpoints click here.