Creating a Data Center object¶

URL:

/api/dc/

Request body:

{
    "dc": {
    "dcname": <string>,
    "address": <string>
    }
}

Request Example:

{
    "dc": {
    "dcname": "POP-SP",
    "address": "SP"
    }
}

All fields are required:

• dcname - It is the name of the Data Center.

address - It is the location of the Data Center.

At the end of POST request, it will be returned a json with the Data Center object created.

Response Body:

{
    "dc": {
    "id": 1
    "dcname": "POP-SP",
    "address": "SP"
    }
}

Editing a Data Center object¶

Obtaining list of Data Centers¶

URL:

/api/dc/

Default behavior¶

The response body will look like this:

Response body:

{
    "dc": [{
        "id": <integer>,
        "dcname": <string>,
        "address": <string>,
        "fabric": <list>
    },...]
}

Deleting a Data Center object¶

URL:

/api/dc/<dc_id>/

where dc_id is the identifier of Data Center’s desired to delete.

Example with Parameter ID:

/api/dc/1/

Creating a Fabric object¶

URL:

/api/dcrooms/

Request body:

{
    "dcrooms": {
        "dc": <integer:dc_fk>,
        "name": <string>,
        "racks": <integer>,
        "spines": <integer>,
        "leafs": <integer>,
        "config": <dict>
    }
}

Request Example:

{
    "dcrooms": {
        "dc": 1,
        "name":"Fabric name",
        "racks": 32,
        "spines": 4,
        "leafs": 2,
        "config": {}
    }
}

• dc - It is the fk of the Data Center.

name - It is the name of the Fabric. racks - Total number of the racks in a fabric. spines - Total number of the spines in a fabric. leafs - Total number of the leafes in a fabric. config - Json with the father’s environments related to the fabric and it’s peculiarities.

Only fields ‘dc’ and ‘name’ are required.

Example of config json:

{
  "BGP": {
    "spines": <string: AS Number>,
    "mpls": <string: AS Number>,
    "leafs": <string: AS Number>
  },
  "Gerencia": {
    "telecom": {
      "vlan": <string: Vlan Number>,
      "rede": <string: IPv4 Net>
    }
  },
  "VLT": {
    "id_vlt_lf1": <string: VLT ID Number>,
    "priority_vlt_lf1": <string: VLT priority Number>,
    "priority_vlt_lf2": <string: VLT priority Number>,
    "id_vlt_lf2": <string: VLT ID Number>
  },
  "Ambiente": [
    {
      "id": <integer: env_fk>,
      "details": [
        {
          "name": <string: Name of the new environment - E.g.: BEFE>,
          "min_num_vlan_1": <integer: Minimum number for Vlan>,
          "max_num_vlan_1": <integer: Maximum number for Vlan>,
          "config": [
            {
              "subnet": <string: IPv4 or IPv6 Net>,
              "type": <string: v4 or v6>,
              "mask": <integer: net mask>,
              "network_type": <integer: net_type_fk>,
              "new_prefix": <integer: subnet mask>
            },...
          ]
        }, ...
      ]
    },
    {
      "id": <integer: env_fk>,
      "details": []
    },...
    {
      "id": <integer: env_fk>,
      "details": [
        {
          "v4": {
            "new_prefix": <string: subnet mask>
          },
          "v6": {
            "new_prefix": <string: subnet mask>
          }
        }
      ]
    },...
  ],
  "Channel": {
    "channel": <string: Port Channel base Number>
  }
}

At the end of POST request, it will be returned a json with the Fabric object created.

Response Body:

{
    "dcrooms": {
        "id": 1
        "dc": 1,
        "name":"Fabric name",
        "racks": 32,
        "spines": 4,
        "leafs": 2,
        "config": {}
    }
}

Obtaining list of Fabrics¶

URL:

/api/dcrooms/

Get a Fabric by id¶

URL:

/api/dcrooms/<fabric_fk>

where fabric_fk is the identifier of the fabric desired to be retrieved.

Get a Fabric by the datacenters id¶

URL:

/api/dcrooms/dc/<dc_fk>

where dc_fk is the identifier of the datacenter.

Default behavior¶

The response body will look like this:

Response body:

{
    "fabric": [{
        "id": 32,
        "name": "POPF",
        "dc": 3,
        "racks": 8,
        "spines": 4,
        "leafs": 2,
        "config": {...}
    },
    ...]
}

Editing a Fabric object¶

URL:

/api/dcrooms/

Request body:

{
    "dcrooms": {
        "id": <interger:fabric_fk>,
        "dc": <integer:dc_fk>,
        "name": <string>,
        "racks": <integer>,
        "spines": <integer>,
        "leafs": <integer>,
        "config": <dict>
    }
}

Request Example:

{
    "dcrooms": {
        "id": 1,
        "dc": 1,
        "name":"Fabric name",
        "racks": 32,
        "spines": 4,
        "leafs": 2,
        "config": {...}
    }
}

Through Fabric PUT route you can update a object. These fields are required:

• id - It is the fk of the Fabric.

dc - It is the fk of the Data Center. name - It is the name of the Fabric.

At the end of PUT request, it will be returned the Fabric object updated.

Response Body:

{

“dcrooms”: {

“id”: 1 “dc”: 1, “name”:”Fabric name”, “racks”: 32, “spines”: 4, “leafs”: 2, “config”: {...}

}

}

Deleting a Fabric object¶

URL:

/api/dcrooms/

Obtaining list of Racks¶

URL:

/api/rack/

/api/rack/fabric/<fabric_fk>

/api/rack/<rack_fk>

{
    "racks": [{
        "config": false,
        "create_vlan_amb": false,
        "dcroom": 1,
        "id": 10,
        "id_ilo": "OOB-CM-TE01",
        "id_sw1": "LF-CM-TE01-1",
        "id_sw2": "LF-CM-TE01-2",
        "mac_ilo": "3F:FF:FF:FF:FF:10",
        "mac_sw1": "1F:FF:FF:FF:FF:10",
        "mac_sw2": "2F:FF:FF:FF:FF:10",
        "nome": "TE10",
        "numero": 10
        },...
    ]
}

Creating a Rack object¶

URL:

/api/rack/

Request body:

{
    "rack":{
        "name": <string>,
        "number": <integer>,
        "mac_sw1": <string:mac_address>,
        "mac_sw2": <string:mac_address>,
        "mac_ilo": <string:mac_address>,
        "id_sw1": <integer:equipment_fk>,
        "id_sw2": <integer:equipment_fk>,
        "id_ilo": <integer:equipment_fk>,
        "dcroom": <integer:fabric_fk>
    }
}

Request Example:

{
    "rack":{
        "name": "TE01",
        "number": 2,
        "mac_sw1": "1F:FF:FF:FF:FF:FF",
        "mac_sw2": "2F:FF:FF:FF:FF:FF",
        "mac_ilo": "3F:FF:FF:FF:FF:FF",
        "id_sw1": 1,
        "id_sw2": 2,
        "id_ilo": 3,
        "dcroom": 16
    }
}

• dcroom - It is the fk of the Fabric.

name - It is the name of the Rack. number - It is the number of the Rack. mac_sw[1,2] - It is the mac address from each switch. id_sw[1,2] - It is the fk from each switch.

Only fields ‘name’ and ‘number’ are required.

At the end of POST request, it will be returned a json with the Rack object created.

Response Body:

{
    "rack": {
        "config": false,
        "create_vlan_amb": false,
        "dcroom": 16,
        "id": 10,
        "id_ilo": 3,
        "id_sw1": 1,
        "id_sw2": 2,
        "mac_ilo": "3F:FF:FF:FF:FF:FF",
        "mac_sw1": "1F:FF:FF:FF:FF:FF",
        "mac_sw2": "2F:FF:FF:FF:FF:FF",
        "nome": TE01,
        "numero": 2
        }
}

Editing a Rack object¶

URL:

/api/rack/<rack_fk>

Request body:

{

“rack”:

{

“config”: <boolean>, “create_vlan_amb”: <boolean>, “fabric_id”: <integer:fabric_id>, “id”: <integer:rack_id>, “id_ilo”: <integer:equipment_id>, “id_sw1”: <integer:equipment_id>, “id_sw2”: <integer:equipment_id>, “mac_ilo”: <string:mac_address>, “mac_sw1”: <string:mac_address>, “mac_sw2”: <string:mac_address>, “nome”: “PUT10”, “numero”: <integer>

}

}

Request Example:

{

“rack”:

{

“config”: false, “create_vlan_amb”: false, “fabric_id”: 1, “id”: 10, “id_ilo”: 3, “id_sw1”: 1, “id_sw2”: 2, “mac_ilo”: “3F:FF:FF:FF:FF:FF”, “mac_sw1”: “1F:FF:FF:FF:FF:FF”, “mac_sw2”: “2F:FF:FF:FF:FF:FF”, “nome”: “PUT10”, “numero”: 10

}

}

Through PUT route you can update a rack object. These fields are required:

• id - It is the fk of the rack.

numero - It is the number of the rack. nome - It is the name of the rack.

At the end of PUT request, it will be returned the rack object updated.

Response Body:

{

“rack”: {

“config”: false, “create_vlan_amb”: false, “dcroom”: 1, “id”: 10, “id_ilo”: “OOB-CM-TE01”, “id_sw1”: “LF-CM-TE01-1”, “id_sw2”: “LF-CM-TE01-2”, “mac_ilo”: “3F:FF:FF:FF:FF:FF”, “mac_sw1”: “1F:FF:FF:FF:FF:FF”, “mac_sw2”: “2F:FF:FF:FF:FF:FF”, “nome”: null, “numero”: null

}

}

Deleting a Rack object¶

URL:

/api/rack/<rack_fk>/

where rack_fk is the identifier of Rack’s desired to delete.

Example with Parameter ID:

/api/rack/1/

Obtaining list of Environments¶

It is possible to specify in several ways fields desired to be retrieved in Environment module through the use of some GET parameters. You are not required to use these parameters, but depending on your needs it can make your requests faster if you are dealing with many objects and you need few fields. The following fields are available for Environment module (hyperlinked or bold marked fields acts as foreign keys and can be expanded using __basic or __details when using fields, include or exclude GET Parameters. Hyperlinked fields points to its documentation):

• id
• name
• grupo_l3
• ambiente_logico
• divisao_dc
• filter
• acl_path
• ipv4_template
• ipv6_template
• link
• min_num_vlan_1
• max_num_vlan_1
• min_num_vlan_2
• max_num_vlan_2
• vrf
• default_vrf
• father_environment
• children
• configs
• routers
• equipments

/api/v3/environment/[environment_ids]/

/api/v3/environment/1/

/api/v3/environment/1;3;8/

:ref:`Django QuerySet API reference <https://docs.djangoproject.com/el/1.10/ref/models/querysets/>`_

/api/v3/environment/

search=[encoded dict]

/api/v3/environment/?search=[encoded dict]

{
    "extends_search": [{
        "divisao_dc": 1,
        "ambiente_logico__nome": "AmbLog"
    }],
    "start_record": 0,
    "custom_search": "",
    "end_record": 25,
    "asorting_cols": [],
    "searchable_columns": []
}

Using fields GET parameter¶

Through fields, you can specify desired fields.

Example with field id:

fields=id

Example with fields id, name and grupo_l3:

fields=id,name,grupo_l3

Using kind GET parameter¶

The Environment module also accepts the kind GET parameter. Only two values are accepted by kind: basic or details. For each value it has a set of default fields. The difference between them is that in general details contains more fields than basic, and the common fields between them are more detailed for details.

Example with basic option:

kind=basic

Response body with basic kind:

{
    "environments": [{
        "id": <integer>,
        "name": <string>
    }]
}

Example with details option:

kind=details

Response body with details kind:

{
    "environments": [{
        "id": <integer>,
        "name": <string>,
        "grupo_l3": {
            "id": <integer>,
            "name": <string>
        },
        "ambiente_logico": {
            "id": <integer>,
            "name": <string>
        },
        "divisao_dc": {
            "id": <integer>,
            "name": <string>
        },
        "filter": <integer>,
        "acl_path": <string>,
        "ipv4_template": <string>,
        "ipv6_template": <string>,
        "link": <string>,
        "min_num_vlan_1": <integer>,
        "max_num_vlan_1": <integer>,
        "min_num_vlan_2": <integer>,
        "max_num_vlan_2": <integer>,
        "default_vrf": {
            "id": <integer>,
            "internal_name": <string>,
            "vrf": <string>
        },
        "father_environment": <recurrence-to:environment>
    }]
}

Using fields and kind together¶

If fields is being used together kind, only the required fields will be retrieved instead of default.

Example with details kind and id field:

kind=details&fields=id

Default behavior without kind and fields¶

If neither kind nor fields are used in request, the response body will look like this:

Response body:

{
    "environments": [{
        "id": <integer>,
        "name": <string>,
        "grupo_l3": <integer>,
        "ambiente_logico": <integer>,
        "divisao_dc": <integer>,
        "filter": <integer>,
        "acl_path": <string>,
        "ipv4_template": <string>,
        "ipv6_template": <string>,
        "link": <string>,
        "min_num_vlan_1": <integer>,
        "max_num_vlan_1": <integer>,
        "min_num_vlan_2": <integer>,
        "max_num_vlan_2": <integer>,
        "default_vrf": <integer>,
        "father_environment": <integer>
    },...]
}

Obtaining environments associated to environment vip¶

URL:

/api/v3/environment/environment-vip/<environment_vip_id>/

where environment_vip_id is the identifier of the environment vip used as an argument to retrieve associated environments. Only one environment_vip_id can be assigned. The instruction related to use of extra GET parameters (kind, fields, include and exclude) and the default response body is the same as described in Environment GET Module

Example:

/api/v3/environment/environment-vip/1/

Obtaining list of Environment Vip¶

It is possible to specify in several ways fields desired to be retrieved in Environment Vip module through the use of some GET parameters. You are not required to use these parameters, but depending on your needs it can make your requests faster if you are dealing with many objects and you need few fields. The following fields are available for Environment Vip module (hyperlinked or bold marked fields acts as foreign keys and can be expanded using __basic or __details when using fields, include or exclude GET Parameters. Hyperlinked fields points to its documentation. Some expandable fields that do not have documentation have its childs described here too because some of these childs are also expandable):

• id
• finalidade_txt
• cliente_txt
• ambiente_p44_txt
• description
• name
• conf

• optionsvip

  • option
  • environment_vip

• environments

  • environment
  • environment_vip

/api/v3/environment-vip/[environment_vip_ids]/

/api/v3/environment-vip/1/

/api/v3/environment-vip/1;3;8/

:ref:`Django QuerySet API reference <https://docs.djangoproject.com/el/1.10/ref/models/querysets/>`_

/api/v3/environment-vip/

search=[encoded dict]

/api/v3/environment-vip/?search=[encoded dict]

{
    "extends_search": [{
        "description__icontains": "BE",
    }],
    "start_record": 0,
    "custom_search": "",
    "end_record": 25,
    "asorting_cols": [],
    "searchable_columns": []
}

Using fields GET parameter¶

Through fields, you can specify desired fields.

Example with field id:

fields=id

Example with fields id, name and environments:

fields=id,name,environments

Using kind GET parameter¶

The Environment Vip module also accepts the kind GET parameter. Only two values are accepted by kind: basic or details. For each value it has a set of default fields. The difference between them is that in general details contains more fields than basic, and the common fields between them are more detailed for details.

Example with basic option:

kind=basic

Response body with basic kind:

{
    "environments_vip": [{
        "id": <integer>,
        "name": <string>
    },...]
}

Example with details option:

kind=details

Response body with details kind:

{
    "environments_vip": [{
        "id": <integer>,
        "finalidade_txt": <string>,
        "cliente_txt": <string>,
        "ambiente_p44_txt": <string>,
        "description": <string>,
        "name": <string>,
        "conf": <string>
    },...]
}

Using fields and kind together¶

If fields is being used together kind, only the required fields will be retrieved instead of default.

Example with details kind and id field:

kind=details&fields=id

Default behavior without kind and fields¶

If neither kind nor fields are used in request, the response body will look like this:

Response body:

{
    "environments_vip": [{
        "id": <integer>,
        "finalidade_txt": <string>,
        "cliente_txt": <string>,
        "ambiente_p44_txt": <string>,
        "description": <string>
    },...]
}

Obtaining finality list¶

URL:

/api/v3/environment-vip/step/

Optional GET Parameter:

environmentp44=[string]

Example:

Without environmentp44 GET Parameter:

/api/v3/environment-vip/step/

With environmentp44 GET Parameter:

/api/v3/environment-vip/step/?environmentp44=[string]

where environmentp44 is a characteristic of environment vips. This argument is not case sensitive. The URL above accepts other GET Parameters, but the type of response will be different depending on what GET Parameters are sent to API. Therefore, to obtain finality list, the URL should have no argument or have the optional environmentp44 argument. Don’t forget to encode URL.

Response body:

[
    {
        "finalidade_txt": <string>
    },...
]

Obtaining client list through finality¶

URL:

/api/v3/environment-vip/step/

Required GET Parameter:

finality=[string]

Example:

/api/v3/environment-vip/step/?finality=[string]

where finality is a characteristic of environment vips. This argument is not case sensitive. The URL above accepts other GET Parameters, but the type of response will be different depending on what GET Parameters are sent to API. Therefore, to obtain client list ONLY pass finality parameter into URL. Don’t forget to encode URL.

Response body:

[
    {
        "cliente_txt": <string>
    },...
]

Obtaining environment vip list through finality and client¶

URL:

/api/v3/environment-vip/step/

Required GET Parameters:

finality=[string]
client=[string]

Example:

/api/v3/environment-vip/step/?finality=[string]&client=[string]

where finality and client are characteristics of environment vips. These arguments are not case sensitive. The URL above accepts other GET Parameters, but the type of response will be different depending on what GET Parameters are sent to API. Therefore, to obtain environment list ONLY pass finality and client parameters into URL. Don’t forget to encode URL. The instruction related to use of extra GET parameters (kind, fields, include and exclude) and the default response body is the same as described in Environment Vip GET Module.

Response body:

[
    {
        "id": <integer>,
        "finalidade_txt": <string>,
        "cliente_txt": <string>,
        "ambiente_p44_txt": <string>,
        "description": <string>
    },...
]

Obtaining environment vip through finality, client and environmentp44¶

URL:

/api/v3/environment-vip/step/

Required GET Parameters:

finality=[string]
client=[string]
environmentp44=[string]

Example:

/api/v3/environment-vip/step/?finality=[string]&client=[string]&environmentp44=[string]

where finality, client and environmentp44 are characteristics of environment vips. These arguments are not case sensitive . To obtain only one environment vip you must pass the three parameters described above into URL. Don’t forget to encode URL. The instruction related to use of extra GET parameters (kind, fields, include and exclude) and the default response body is the same as described in Environment Vip GET Module.

Response body:

[
    {
        "id": <integer>,
        "finalidade_txt": <string>,
        "cliente_txt": <string>,
        "ambiente_p44_txt": <string>,
        "description": <string>
    },...
]

Obtaining list of Equipments¶

It is possible to specify in several ways fields desired to be retrieved in Equipment module through the use of some GET parameters. You are not required to use these parameters, but depending on your needs it can make your requests faster if you are dealing with many objects and you need few fields. The following fields are available for Equipment module (hyperlinked or bold marked fields acts as foreign keys and can be expanded using __basic or __details when using fields, include or exclude GET Parameters. Hyperlinked fields points to its documentation. Some expandable fields that do not have documentation have its childs described here too because some of these childs are also expandable.):

• id
• name
• maintenance
• equipment_type

• model

  • name

  • brand

    • id
    • name

• ipv4
• ipv6

• environments

  • environment
  • equipment

• groups

/api/v3/equipment/

rights_write=[string]
environment=[integer]
ipv4=[string]
ipv6=[string]
is_router=[integer]
name=[string]

/api/v3/equipment/?ipv4=192.168.0.1&environment=5

/api/v3/equipment/[equipment_ids]/

/api/v3/equipment/1/

/api/v3/equipment/1;3;8/

:ref:`Django QuerySet API reference <https://docs.djangoproject.com/el/1.10/ref/models/querysets/>`_

/api/v3/equipment/

search=[encoded dict]

/api/v3/equipment/?search=[encoded dict]

{
    "extends_search": [{
        "maintenance": false,
        "tipo_equipamento": 1
    }],
    "start_record": 0,
    "custom_search": "",
    "end_record": 25,
    "asorting_cols": [],
    "searchable_columns": []
}

Using fields GET parameter¶

Through fields, you can specify desired fields.

Example with field id:

fields=id

Example with fields id, name and maintenance:

fields=id,name,maintenance

Using kind GET parameter¶

The Equipment module also accepts the kind GET parameter. Only two values are accepted by kind: basic or details. For each value it has a set of default fields. The difference between them is that in general details contains more fields than basic, and the common fields between them are more detailed for details. For example, the field equipment_type for basic will contain only the identifier and for details will contain also the description.

Example with basic option:

kind=basic

Response body with basic kind:

{
    "equipments": [{
        "id": <integer>,
        "name": <string>
    }]
}

Example with details option:

kind=details

Response body with details kind:

{
    "equipments": [{
        "id": <integer>,
        "name": <string>,
        "maintenance": <boolean>,
        "equipment_type": {
            "id": <integer>,
            "equipment_type": <string>
        },
        "model": {
            "id": <integer>,
            "name": <string>
        },
        "ipv4": [{
            "id": <integer>,
            "oct1": <integer>,
            "oct2": <integer>,
            "oct3": <integer>,
            "oct4": <integer>,
            "networkipv4": <integer>,
            "description": <string>
        },...],
        "ipv6": [{
            "id": <integer>,
            "block1": <string>,
            "block2": <string>,
            "block3": <string>,
            "block4": <string>,
            "block5": <string>,
            "block6": <string>,
            "block7": <string>,
            "block8": <string>,
            "networkipv6": <integer>,
            "description": <string>
        },...],
        "environments": [{
            "is_router": <boolean>,
            "environment": {
                "id": <integer>,
                "name": <name>
                "grupo_l3": <integer>,
                "ambiente_logico": <integer>,
                "divisao_dc": <integer>,
                "filter": <integer>,
                "acl_path": <string>,
                "ipv4_template": <string>,
                "ipv6_template": <string>,
                "link": <string>,
                "min_num_vlan_1": <integer>,
                "max_num_vlan_1": <integer>,
                "min_num_vlan_2": <integer>,
                "max_num_vlan_2": <integer>,
                "vrf": <string>,
                "default_vrf": <integer>
            }
        },...],
        "groups": [{
            "id": <integer>,
            "name": <string>
        },...]
    },...]
}

Using fields and kind together¶

If fields is being used together kind, only the required fields will be retrieved instead of default.

Example with details kind and id field:

kind=details&fields=id

Default behavior without kind and fields¶

If neither kind nor fields are used in request, the response body will look like this:

Response body:

{
    "equipments": [{
        "id": <integer>,
        "name": <string>,
        "maintenance": <boolean>,
        "equipment_type": <integer>,
        "model": <integer>
    },...]
}

Creating list of equipments¶

URL:

/api/v3/equipment/

Request body:

{
    "equipments": [{
        "environments": [
            {
                "id": <integer:environment_fk>,
                "is_router": <boolean>
            },...
        ],
        "equipment_type": <integer:equip_type_fk>,
        "groups": [
            {
                "id": <integer:group_fk>
            },...
        ],
        "ipv4": [
            {
                "id": <integer:ipv4_fk>
            }
        ],
        "ipv6" [
            {
                "id": <integer:ipv6_fk>
            }
        ],
        "maintenance": <boolean>,
        "model": <integer:model_fk>,
        "name": <string>
    },...]
}

• environments - You can associate environments to new Equipment and specify if your equipment in each association will act as a router for specific environment.
• equipment_type - You must specify if your Equipment is a Switch, a Router, a Load Balancer...
• groups - You can associate the new Equipment to one or more groups of Equipments.
• ipv4 - You can assign to the new Equipment how many IPv4 addresses is needed.
• ipv6 - You can assign to the new Equipment how many IPv6 addresses is needed.
• maintenance - You must assign to the new Equipment a flag saying if the Equipment is or not in maintenance mode.
• model - You must assign to the Equipment some model (Cisco, Dell, HP, F5, ...).
• name - You must assign to the Equipment any name.

URL Example:

/api/v3/equipment/

Updating list of equipments in database¶

URL:

/api/v3/equipment/[equipment_ids]/

where equipment_ids are the identifiers of equipments. It can use multiple ids separated by semicolons.

Example with Parameter IDs:

One ID:

/api/v3/equipment/1/

Many IDs:

/api/v3/equipment/1;3;8/

Request body:

{
    "equipments": [{
        "id": <integer>,
        "environments": [
            {
                "id": <integer:environment_fk>,
                "is_router": <boolean>
            },...
        ],
        "equipment_type": <integer:equip_type_fk>,
        "groups": [
            {
                "id": <integer:group_fk>
            },...
        ],
        "ipv4": [
            {
                "id": <integer:ipv4_fk>
            }
        ],
        "ipv6" [
            {
                "id": <integer:ipv6_fk>
            }
        ],
        "maintenance": <boolean>,
        "model": <integer:model_fk>,
        "name": <string>
    },..]
}

• environments - You can associate environments to new Equipment and specify if your equipment in each association will act as a router for specific environment.
• equipment_type - You must specify if your Equipment is a Switch, a Router, a Load Balancer...
• groups - You can associate the new Equipment to one or more groups of Equipments.
• ipv4 - You can assign to the new Equipment how many IPv4 addresses is needed.
• ipv6 - You can assign to the new Equipment how many IPv6 addresses is needed.
• maintenance - You must assign to the new Equipment a flag saying if the Equipment is or not in maintenance mode.
• model - You must assign to the Equipment some model (Cisco, Dell, HP, F5, ...).
• name - You must assign to the Equipment any name.

Remember that if you don’t provide the not mandatory fields, actual information (e.g. associations between Equipment and Environments) will be deleted. The effect of PUT Request is always to replace actual data by what you provide into fields in this type of request.

URL Example:

/api/v3/equipment/1/

Deleting a list of equipments in database¶

/api/v3/equipment/[equipment_ids]/

/api/v3/equipment/1/

/api/v3/equipment/1;3;8/

Obtaining options pools associated to environment¶

URL:

/api/v3/option-pool/environment/<environment_id>/

where environment_id is the identifier of the environment used as an argument to retrieve associated option pools. It’s mandatory to assign one and only one environment_id.

Example:

/api/v3/option-pool/environment/1/

Response body:

{
    "options_pool": [{
        "id": <integer>,
        "type": "string",
        "name": "string"
    }, ...]
}

Obtaining list of Options Vip¶

It is possible to specify in several ways fields desired to be retrieved in Options Vip module through the use of some GET parameters. You are not required to use these parameters, but depending on your needs it can make your requests faster if you are dealing with many objects and you need few fields. The following fields are available for Options Vip module (hyperlinked or bold marked fields acts as foreign keys and can be expanded using __basic or __details when using fields, include or exclude GET Parameters. Hyperlinked fields points to its documentation):

• option
• environment_vip

/api/v3/option-vip/environment-vip/<environment_vip_id>

/api/v3/option-vip/environment-vip/1

[
    {
        "option": {
            "id": <integer>,
            "tipo_opcao": <string>,
            "nome_opcao_txt": <string>
        },
        "environment-vip": <integer>
    },...
]

Obtaining options vip through environment vip and type option¶

URL:

/api/v3/option-vip/environment-vip/<environment_vip_id>/type-option/<type_option>/

where environment_vip_id is the identifier of environment vip used as an argument to retrieve associated options vip and type_option is a string that filter the result by some type option. It’ mandatory to assign one and only one identifier for environment_vip_id and a string for type_option. String type_option is not case sensitive.

It is possible to specify in several ways fields desired to be retrieved using the above route through the use of some GET parameters. You are not required to use these parameters, but depending on your needs it can make your requests faster if you are dealing with many objects and you need few fields. The following fields are available for its route (hyperlinked or bold marked fields acts as foreign keys and can be expanded using __basic or __details when using fields, include or exclude GET Parameters. Hyperlinked fields points to its documentation):

• id
• tipo_opcao
• nome_opcao_txt

Example:

/api/v3/option-vip/environment-vip/1/type-option/balanceamento/

Response body:

{

    "optionsvip": [
        [{
            "id": <integer>,
            "tipo_opcao": <string>,
            "nome_opcao_txt": <string>
        },...]
    ]

}

Using fields GET parameter¶

Through fields, you can specify desired fields.

Example with field id:

fields=id

Example with fields id and tipo_opcao:

fields=id,tipo_opcao

Using kind GET parameter¶

The above route also accepts the kind GET parameter. Only two values are accepted by kind: basic or details. For each value it has a set of default fields. The difference between them is that in general details contains more fields than basic, and the common fields between them are more detailed for details.

Example with basic option:

kind=basic

Response body with basic kind:

{
    "optionsvip": [{
        "id": <integer>,
        "tipo_opcao": <string>
    },...]
}

Example with details option:

kind=details

Response body with details kind:

{
    "optionsvip": [{
        "id": <integer>,
        "tipo_opcao": <string>,
        "nome_opcao_txt": <string>
    },...]
}

Using fields and kind together¶

If fields is being used together kind, only the required fields will be retrieved instead of default.

Example with details kind and id field:

kind=details&fields=id

Default behavior without kind and fields¶

If neither kind nor fields are used in request, the response body will look like this:

Response body:

{
    "optionsvip": [{
        "id": <integer>,
        "tipo_opcao": <string>
    },...]
}

Obtaining list of Server Pool¶

It is possible to specify in several ways fields desired to be retrieved in Server Pool module through the use of some GET parameters. You are not required to use these parameters, but depending on your needs it can make your requests faster if you are dealing with many objects and you need few fields. The following fields are available for Server Pool module (hyperlinked or bold marked fields acts as foreign keys and can be expanded using __basic or __details when using fields, include or exclude GET Parameters. Hyperlinked fields points to its documentation. Some expandable fields that do not have documentation have its childs described here too because some of these childs are also expandable.):

• id
• identifier
• default_port
• environment
• servicedownaction
• lb_method
• healthcheck
• default_limit

• server_pool_members

  • id
  • server_pool
  • identifier
  • ip
  • ipv6
  • priority
  • weight
  • limit
  • port_real
  • member_status
  • last_status_update
  • last_status_update_formated
  • equipments
  • equipment

• pool_created
• vips
• dscp
• groups_permissions

/api/v3/pool/<pool_ids>/

/api/v3/pool/1/

/api/v3/pool/1;3;8/

:ref:`Django QuerySet API reference <https://docs.djangoproject.com/el/1.10/ref/models/querysets/>`_

/api/v3/pool/

search=[encoded dict]

/api/v3/pool/?search=[encoded dict]

{
    "extends_search": [{
        "environment": 1
    }],
    "start_record": 0,
    "custom_search": "",
    "end_record": 25,
    "asorting_cols": [],
    "searchable_columns": []
}

Using fields GET parameter¶

Through fields, you can specify desired fields.

Example with field id:

fields=id

Example with fields id, identifier and pool_created:

fields=id,identifier,pool_created

Using kind GET parameter¶

The Server Pool module also accepts the kind GET parameter. Only two values are accepted by kind: basic or details. For each value it has a set of default fields. The difference between them is that in general details contains more fields than basic, and the common fields between them are more detailed for details.

Example with basic option:

kind=basic

Response body with basic kind:

{
    "server_pools": [{
        "id": <integer>,
        "identifier": <string>,
        "pool_created": <boolean>
    },...]
}

Example with details option:

kind=details

Response body with details kind:

{
    "server_pools": [{
        "id": <integer>,
        "identifier": <string>,
        "default_port": <integer>,
        "environment": {
            "id": <integer>,
            "name": <string>
        },
        "servicedownaction": {
            "id": <integer>,
            "type": <string>,
            "name": <string>
        },
        "lb_method": <string>,
        "healthcheck": {
            "identifier": <string>,
            "healthcheck_type": <string>,
            "healthcheck_request": <string>,
            "healthcheck_expect": <string>,
            "destination": <string>
        },
        "default_limit": <integer>,
        "server_pool_members": [{
            "id": <integer>,
            "identifier": <string>,
            "ip": {
                "id": <integer>,
                "ip_formated": <string>
            },
            "ipv6": {
                "id": <integer>,
                "ip_formated": <string>
            },
            "priority": <integer>,
            "weight": <integer>,
            "limit": <integer>,
            "port_real": <integer>,
            "member_status": <integer>,
            "last_status_update_formated": <string>,
            "equipment": {
                "id": <integer>,
                "name": <string>
            }
        }],
        "pool_created": <boolean>
    }]
}

Using fields and kind together¶

If fields is being used together kind, only the required fields will be retrieved instead of default.

Example with details kind and id field:

kind=details&fields=id

Default behavior without kind and fields¶

If neither kind nor fields are used in request, the response body will look like this:

{
    "server_pools": [{
        "id": <server_pool_id>,
        "identifier": <string>,
        "default_port": <integer>,
        environmentvip": <environment_id>,
        "servicedownaction": {
            "id": <optionvip_id>,
            "name": <string>
        },
        "lb_method": <string>,
        "healthcheck": {
            "identifier": <string>,
            "healthcheck_type": <string>,
            "healthcheck_request": <string>,
            "healthcheck_expect": <string>,
            "destination": <string>
        },
        "default_limit": <integer>,
        "server_pool_members": [{
            "id": <server_pool_member_id>,
            "identifier": <string>,
            "ipv6": {
                "ip_formated": <ipv6_formated>,
                "id": <ipv6_id>
            },
            "ip": {
                "ip_formated": <ipv4_formated>,
                "id": <ipv4_id>
            },
            "priority": <integer>,
            "equipment": {
                "id": <integer>,
                "name": <string>
            },
            "weight": <integer>,
            "limit": <integer>,
            "port_real": <integer>,
            "last_status_update_formated": <string>,
            "member_status": <integer>
        },...],
        "pool_created": <boolean>
    },...]
}

Creating list of pools in database:¶

This only affects database, if flag “created” is assigned true, it will be ignored.

URL:

/api/v3/pool/

Request body:

{
    "server_pools": [{
        "id": <null>,
        "identifier": <string>,
        "default_port": <integer>,
        "environmentvip": <environment_id>,
        "servicedownaction": {
            "id": <optionvip_id>,
            "name": <string>
        },
        "lb_method": <string>,
        "healthcheck": {
            "identifier": <string>,
            "healthcheck_type": <string>,
            "healthcheck_request": <string>,
            "healthcheck_expect": <string>,
            "destination": <string>
        },
        "default_limit": <integer>,
        "server_pool_members": [{
            "id": <server_pool_member_id>,
            "identifier": <string>,
            "ipv6": {
                "ip_formated": <ipv6_formated>,
                "id": <ipv6_id>
            },
            "ip": {
                "ip_formated": <ipv4_formated>,
                "id": <ipv4_id>
            },
            "priority": <integer>,
            "equipment": {
                "id": <integer>,
                "name": <string>
            },
            "weight": <integer>,
            "limit": <integer>,
            "port_real": <integer>,
            "last_status_update_formated": <string>,
            "member_status": <integer>
        }],
        "pool_created": <boolean>
    },...]
}

URL Example:

/api/v3/pool/

More information about the POST request can be obtained in:

/api/v3/help/pool_post/

Updating list of server pools in database¶

URL:

/api/v3/pool/<pool_ids>

where pool_ids are the identifiers of each pool desired to be updated. Only pools not deployed to equipments can be updated in this way. To update more than one pool, semicolons between the identifiers should be used.

Example with Parameter IDs:

One ID:

/api/v3/pool/1/

Many IDs:

/api/v3/pool/1;3;8/

Request body:

{
    "server_pools": [{
        "id": <server_pool_id>,
        "identifier": <string>,
        "default_port": <integer>,
        environmentvip": <environment_id>,
        "servicedownaction": {
            "id": <optionvip_id>,
            "name": <string>
        },
        "lb_method": <string>,
        "healthcheck": {
            "identifier": <string>,
            "healthcheck_type": <string>,
            "healthcheck_request": <string>,
            "healthcheck_expect": <string>,
            "destination": <string>
        },
        "default_limit": <integer>,
        "server_pool_members": [{
            "id": <server_pool_member_id>,
            "identifier": <string>,
            "ipv6": {
                "ip_formated": <ipv6_formated>,
                "id": <ipv6_id>
            },
            "ip": {
                "ip_formated": <ipv4_formated>,
                "id": <ipv4_id>
            },
            "priority": <integer>,
            "equipment": {
                "id": <integer>,
                "name": <string>
            },
            "weight": <integer>,
            "limit": <integer>,
            "port_real": <integer>,
            "last_status_update_formated": <string>,
            "member_status": <integer>
        }],
        "pool_created": <boolean>
    },...]
}

More information about the PUT request can be obtained in:

/api/v3/help/pool_put/

Deleting a list of server pools in database¶

URL:

/api/v3/pool/<pool_ids>/

where pool_ids are the identifiers of each pool desired to be deleted. To delete more than one pool, semicolons between the identifiers should be used. If at least one pool assigned to pool_ids exists in equipment, an exception will be raised.

Example with Parameter IDs:

One ID:

/api/v3/pool/1/

Many IDs:

/api/v3/pool/1;3;8/

Obtaining list of pools with member states updated¶

URL:

/api/v3/pool/deploy/<pool_ids>/member/status/

where pool_ids are the identifiers of each pool desired to be obtained. To obtain more than one pool, semicolons between the identifiers should be used.

GET Param:

checkstatus=[0|1]

To obtain member states updated, checkstatus should be assigned to 1. If it is assigned to 0, server pools will be retrieved but the real status of the equipments will not be checked in the equipment.

Response body:

{
    "server_pools": [{
        "id": <server_pool_id>,
        "identifier": <string>,
        "default_port": <integer>,
        environmentvip": <environment_id>,
        "servicedownaction": {
            "id": <optionvip_id>,
            "name": <string>
        },
        "lb_method": <string>,
        "healthcheck": {
            "identifier": <string>,
            "healthcheck_type": <string>,
            "healthcheck_request": <string>,
            "healthcheck_expect": <string>,
            "destination": <string>
        },
        "default_limit": <integer>,
        "server_pool_members": [{
            "id": <server_pool_member_id>,
            "identifier": <string>,
            "ipv6": {
                "ip_formated": <ipv6_formated>,
                "id": <ipv6_id>
            },
            "ip": {
                "ip_formated": <ipv4_formated>,
                "id": <ipv4_id>
            },
            "priority": <integer>,
            "equipment": {
                "id": <integer>,
                "name": <string>
            },
            "weight": <integer>,
            "limit": <integer>,
            "port_real": <integer>,
            "last_status_update_formated": <string>,
            "member_status": <integer>
        }],
        "pool_created": <boolean>
    },...]
}

Creating list of pools in equipments¶

URL:

/api/v3/pool/deploy/<pool_ids>/

where pool_ids are the identifiers of each pool desired to be deployed. These pools must exist in database. To deploy more than one pool, semicolons between the identifiers should be used.

Example with Parameter IDs:

One ID:

/api/v3/pool/1/

Many IDs:

/api/v3/pool/1;3;8/

Enabling/Disabling pool member by list of server pool¶

URL:

/api/v3/pool/deploy/<pool_ids>/member/status/

where pool_ids are the identifiers of each pool desired to be updated. To update more than one pool, semicolons between the identifiers should be used.

Example with Parameter IDs:

One ID:

/api/v3/pool/deploy/1/member/status/

Many IDs:

/api/v3/pool/deploy/1;3;8/member/status/

Request body:

{
    "server_pools": [{
        "id": <server_pool_id>,
        "server_pool_members": [{
            "id": <server_pool_member_id>,
            "member_status": <integer>
        }]
    },...]
}

More information about the PUT request can be obtained in:

/api/v3/help/pool_put/

Updating pools by list in equipments¶

URL:

/api/v3/pool/deploy/<pool_ids>/

Request body:

{
    "server_pools": [{
        "id": <server_pool_id>,
        "identifier": <string>,
        "default_port": <integer>,
        environmentvip": <environment_id>,
        "servicedownaction": {
            "id": <optionvip_id>,
            "name": <string>
        },
        "lb_method": <string>,
        "healthcheck": {
            "identifier": <string>,
            "healthcheck_type": <string>,
            "healthcheck_request": <string>,
            "healthcheck_expect": <string>,
            "destination": <string>
        },
        "default_limit": <integer>,
        "server_pool_members": [{
            "id": <server_pool_member_id>,
            "identifier": <string>,
            "ipv6": {
                "ip_formated": <ipv6_formated>,
                "id": <ipv6_id>
            },
            "ip": {
                "ip_formated": <ipv4_formated>,
                "id": <ipv4_id>
            },
            "priority": <integer>,
            "equipment": {
                "id": <integer>,
                "name": <string>
            },
            "weight": <integer>,
            "limit": <integer>,
            "port_real": <integer>,
            "last_status_update_formated": <string>,
            "member_status": <integer>
        }],
        "pool_created": <boolean>
    },...]
}

URL Example:

/api/v3/pool/

More information about the PUT request can be obtained in:

/api/v3/help/pool_put/

Deleting a list of server pools in equipments¶

URL:

/api/v3/pool/deploy/<pool_ids>/

where pool_ids are the identifiers of each pool desired to be deleted only in equipment. In database these server pools will not be deleted, but only flag “created” of each server pool will be changed to “false”. To delete more than one pool in equipment, semicolons between the identifiers should be used.

Example with Parameter IDs:

One ID:

/api/v3/pool/deploy/1/

Many IDs:

/api/v3/pool/deploy/1;3;8/

Obtaining server pools with some more details through id’s¶

URL:

/api/v3/pool/details/<pool_ids>/

where pool_ids are the identifiers of each pool desired to be obtained. To obtain more than one pool, semicolons between the identifiers should be used.

Example with Parameter IDs:

One ID:

/api/v3/pool/details/1/

Many IDs:

/api/v3/pool/details/1;3;8/

Response body:

{
    "server_pools": [{
        "id": <server_pool_id>,
        "identifier": <string>,
        "default_port": <integer>,
        "environmentvip": {
            "id": <environment_id>,
            "finalidade_txt": <string>,
            "cliente_txt": <string>,
            "ambiente_p44_txt": <string>,
            "description": <string>
        }
        "servicedownaction": {
            "id": <optionvip_id>,
            "name": <string>
        },
        "lb_method": <string>,
        "healthcheck": {
            "identifier": <string>,
            "healthcheck_type": <string>,
            "healthcheck_request": <string>,
            "healthcheck_expect": <string>,
            "destination": <string>
        },
        "default_limit": <integer>,
        "server_pool_members": [{
            "id": <server_pool_member_id>,
            "identifier": <string>,
            "ipv6": {
                "ip_formated": <ipv6_formated>,
                "id": <ipv6_id>
            },
            "ip": {
                "ip_formated": <ipv4_formated>,
                "id": <ipv4_id>
            },
            "priority": <integer>,
            "equipment": {
                "id": <integer>,
                "name": <string>
            },
            "weight": <integer>,
            "limit": <integer>,
            "port_real": <integer>,
            "last_status_update_formated": <string>,
            "member_status": <integer>
        }],
        "pool_created": <boolean>
    },...]
}

Obtaining server pools with some more details through extended search¶

URL:

/api/v3/pool/details/

GET Parameter:

search=[encoded dict]

Example:

/api/v3/pool/details/?search=[dict encoded]

Request body:

{
    'extends_search': [{
        'environment': <environment_id>
    }],
    'start_record': <integer>,
    'custom_search': '<string>',
    'end_record': <integer>,
    'asorting_cols': [<string>,..],
    'searchable_columns': [<string>,..]
}

Request body example:

{
    'extends_search': [{
        'environment': 1
    }],
    'start_record': 0,
    'custom_search': 'pool_123',
    'end_record': 25,
    'asorting_cols': ['identifier'],
    'searchable_columns': [
        'identifier',
        'default_port',
        'pool_created',
        'healthcheck__healthcheck_type'
    ]
}

Response body:

{
    "total": <integer>,
    "server_pools": [...]
}

Obtaining server pools associated to environment vips¶

URL:

/api/v3/pool/environment-vip/<environment_vip_id>/

where environment_vip_id is the identifier of the environment vip used as an argument to retrieve associated server pools. It’s mandatory to assign one and only one identifier to environment_vip_id. The instruction related to use of extra GET parameters (kind, fields, include and exclude) and the default response body is the same as described in Server Pool GET Module. The only difference is that fields GET parameter is always initialized by default with ‘id’ and ‘identifier’ fields.

Example:

/api/v3/pool/environment-vip/1/

Deploying list of Server Pool asynchronously¶

URL:

/api/v3/pool/deploy/async/[pool_ids]/

You can also deploy Server Pool objects asynchronously. It is only necessary to provide the same as in the respective synchronous request, where pool_ids are the identifiers of Server Pool objects desired to be deployed separated by commas. In this case, when you make request NetworkAPI will create a task to fullfil it. You will not receive the identifier of each Server Pool desired to be deployed in response, but for each Server Pool you will receive an identifier for the created task. Since this is an asynchronous request, it may be that Server Pool objects be deployed after you receive the response. It is your task, therefore, to consult the API through the available means to verify that your request have been met.

URL Example with one identifier:

/api/v3/pool/deploy/async/

URL Example with one identifier:

/api/v3/pool/deploy/async/1;3;8/

Response body:

[
    {
        "task_id": [string with 36 characters]
    },...
]

Response Example for Deploying two Server Pool objects:

[
    {
        "task_id": "36dc887e-48bf-4c83-b6f5-281b70976a8f"
    },
    {
        "task_id": "17ebd466-0231-4bd0-8f78-54ed20238fa3"
    }
]

Updating and Redeploying list of Server Pool asynchronously¶

URL:

/api/v3/pool/deploy/async/[pool_ids]/

You can also update and redeploy Server Pool objects asynchronously. It is only necessary to provide the same as in the respective synchronous request (For more information about request body please check Synchronous Server Pool Update and Redeploy). In this case, when you make request NetworkAPI will create a task to fullfil it. You will not receive the identifier of each Server Pool desired to be updated and redeployed in response, but for each Server Pool you will receive an identifier for the created task. Since this is an asynchronous request, it may be that Server Pool objects be updated and redeployed after you receive the response. It is your task, therefore, to consult the API through the available means to verify that your request have been met.

URL Example:

/api/v3/pool/deploy/async/[pool_ids]/

Response body:

[
    {
        "task_id": [string with 36 characters]
    },...
]

Response Example for Updating and Redeploying two Server Pool objects:

[
    {
        "task_id": "36dc887e-48bf-4c83-b6f5-281b70976a8f"
    },
    {
        "task_id": "17ebd466-0231-4bd0-8f78-54ed20238fa3"
    }
]

Undeploying list of Server Pool asynchronously¶

URL:

/api/v3/pool/deploy/async/[pool_ids]/

You can also undeploy Server Pool objects asynchronously. It is only necessary to provide the same as in the respective synchronous request, where pool_ids are the identifiers of Server Pool objects desired to be undeployed separated by commas. In this case, when you make request NetworkAPI will create a task to fullfil it. You will not receive the identifier of each Server Pool desired to be undeployed in response, but for each Server Pool you will receive an identifier for the created task. Since this is an asynchronous request, it may be that Server Pool objects be undeployed after you receive the response. It is your task, therefore, to consult the API through the available means to verify that your request have been met.

URL Example with one identifier:

/api/v3/pool/deploy/async/

URL Example with one identifier:

/api/v3/pool/deploy/async/1;3;8/

Response body:

[
    {
        "task_id": [string with 36 characters]
    },...
]

Response Example for Undeploying two Server Pool objects:

[
    {
        "task_id": "36dc887e-48bf-4c83-b6f5-281b70976a8f"
    },
    {
        "task_id": "17ebd466-0231-4bd0-8f78-54ed20238fa3"
    }
]

Obtaining options vip through environment vip and type option¶

URL:

/api/v3/type-option/environment-vip/<environment_vip_id>/

where environment_vip_id are the identifiers of environment vips used as an argument to retrieve associated type options. It can use multiple id’s separated by semicolons.

Example:

/api/v3/type-option/environment-vip/1/

Response body:

[
    [
        <string>,...
    ],...
]

Obtaining list of Vip Request¶

It is possible to specify in several ways fields desired to be retrieved in Vip Request module through the use of some GET parameters. You are not required to use these parameters, but depending on your needs it can make your requests faster if you are dealing with many objects and you need few fields. The following fields are available for Vip Request module (hyperlinked or bold marked fields acts as foreign keys and can be expanded using __basic or __details when using fields, include or exclude GET Parameters. Hyperlinked fields points to its documentation):

• id
• name
• service
• business
• environmentvip
• ipv4
• ipv6
• equipments
• default_names
• dscp
• ports
• options
• groups_permissions
• created

Where:

• “environmentvip” attribute is an integer that identifies the environment vip associated to the retrieved vip request.

• “options” are the configured options vip associated to the retrieved vip request.

  • cache-group, persistence, timeout and traffic_return are some values present in the database. These values are configured to a set of restricted values.

• “ports” are the configured ports associated to the retrieved vip request.

  • l4_protocol and l7_protocol in options and l7_rule in pools work as well as the values present in “options” discussed above.
  • “server_pool” is the identifier of the server-pool port associated to the retrieved vip request.

/api/v3/vip-request/[vip_request_ids]/

/api/v3/vip-request/1/

/api/v3/vip-request/1;3;8/

:ref:`Django QuerySet API reference <https://docs.djangoproject.com/el/1.10/ref/models/querysets/>`_

/api/v3/vip-request/

search=[encoded dict]

/api/v3/vip-request/?search=[encoded dict]

{
    "extends_search": [{
        "ipv4__oct1": "192",
        "ipv4__oct2": "168",
        "created": true
        },
    {
        "ipv4__oct2": "168",
        "ipv4__oct3": "17",
        "created": false
    }],
    "start_record": 0,
    "custom_search": "",
    "end_record": 25,
    "asorting_cols": [],
    "searchable_columns": []
}

{
    "extends_search": [{
        "ipv4__vlan__nome__icontains": "G1",
        "ipv4__oct1": "192",
        "created": true
        }
    ],
    "start_record": 0,
    "custom_search": "",
    "end_record": 25,
    "asorting_cols": [],
    "searchable_columns": []
}

/api/v3/vip-request/?search=%22%7B+++++%22extends_search%22%3A+%5B%7B+++++++++%22ipv4__oct1%22%3A+%22192%22%2C+++++++++%22ipv4__oct2%22%3A+%22168%22%2C+++++++++%22created%22%3A+true+++++++++%7D%2C+++++%7B+++++++++%22ipv4__oct2%22%3A+%22168%22%2C+++++++++%22ipv4__oct3%22%3A+%2217%22%2C+++++++++%22created%22%3A+false+++++%7D%5D%2C+++++%22start_record%22%3A+0%2C+++++%22custom_search%22%3A+%22%22%2C+++++%22end_record%22%3A+25%2C+++++%22asorting_cols%22%3A+%5B%5D%2C+++++%22searchable_columns%22%3A+%5B%5D+%7D%22

/api/v3/vip-request/?search=%7B+++++++++%22extends_search%22%3A+%5B%7B+++++++++++++%22ipv4__vlan__nome__icontains%22%3A+%22TVGLOBO%22+%2C+++++++++++++%22ipv4__oct1%22%3A+%22192%22%2C+++++++++++++%22created%22%3A+true+++++++++++++%7D%2C+++++++++%7B+++++++++++++%22ipv4__vlan_nome__icontains%22%3A+%22G1%22%2C+++++++++++++%22ipv4__oct2%22%3A+%22168%22%2C+++++++++++++%22created%22%3A+false+++++++++%7D%5D%2C+++++++++%22start_record%22%3A+0%2C+++++++++%22custom_search%22%3A+%22%22%2C+++++++++%22end_record%22%3A+25%2C+++++++++%22asorting_cols%22%3A+%5B%5D%2C+++++++++%22searchable_columns%22%3A+%5B%5D+++++%7D

Using fields GET parameter¶

Through fields, you can specify desired fields.

Example with field id:

fields=id

Example with fields id, name and created:

fields=id,name,created

Using kind GET parameter¶

The Vip Request module also accepts the kind GET parameter. Only two values are accepted by kind: basic or details. For each value it has a set of default fields. The difference between them is that in general details contains more fields than basic, and the common fields between them are more detailed for details. For example, the field ipv4 for basic will contain only the identifier and for details will contain name, the ip formated and description.

Example with basic option:

kind=basic

Response body with basic kind:

{
    "vips": [{
        "id": <integer>,
        "name": <string>,
        "ipv4": <integer>,
        "ipv6": <integer>
    }]
}

Example with details option:

kind=details

Response body with details kind:

{
    "vips": [{
        "id": <integer>,
        "name": <string>,
        "service": <string>,
        "business": <string>,
        "environmentvip": {
            "id": <integer>,
            "finalidade_txt": <string>,
            "cliente_txt": <string>,
            "ambiente_p44_txt": <string>,
            "description": <string>
        },
        "ipv4": {
            "id": <integer>,
            "ip_formated": <string>,
            "description": <string>
        },
        "ipv6": {
            "id": <integer>,
            "ip_formated": <string>,
            "description": <string>
        },
        "equipments": [{
            "id": <integer>,
            "name": <string>,
            "maintenance": <boolean>,
            "equipment_type": {
                "id": <integer>,
                "equipment_type": <string>
            },
            "model": {
                "id": <integer>,
                "name": <string>
            }
        },...],
        "default_names": [
            <string>,...
        ],
        "dscp": <integer>,
        "ports": [{
            "id": <integer>,
            "port": <integer>,
            "options": {
                "l4_protocol": {
                    "id": <integer>,
                    "tipo_opcao": <string>,
                    "nome_opcao_txt": <string>
                },
                "l7_protocol": {
                    "id": <integer>,
                    "tipo_opcao": <string>,
                    "nome_opcao_txt": <string>
                }
            },
            "pools": [{
                "id": <integer>,
                "server_pool": {
                    "id": <integer>,
                    "identifier": <string>,
                    "default_port": <integer>,
                    "environment": {
                        "id": <integer>,
                        "name": <string>
                    },
                    "servicedownaction": {
                        "id": <integer>,
                        "type": <string>,
                        "name": <string>
                    },
                    "lb_method": <string>,
                    "healthcheck": {
                        "identifier": <string>,
                        "healthcheck_type": <string>,
                        "healthcheck_request": <string>,
                        "healthcheck_expect": <string>,
                        "destination": <string>
                    },
                    "default_limit": <integer>,
                    "server_pool_members": [{
                        "id": <integer>,
                                                    "server_pool": <integer>,
                                                    "identifier": <string>,
                                                    "ip": {
                                                            "id": <integer>,
                                                            "ip_formated": <string>
                                                    },
                                                    "ipv6": {
                                                            "id": <integer>,
                                                            "ip_formated": <string>
                                                    },
                                                    "priority": <integer>,
                                                    "weight": <integer>,
                                                    "limit": <integer>,
                                                    "port_real": <integer>,
                                                    "member_status": <integer>,
                                                    "last_status_update_formated": <string>,
                                                    "equipment": {
                                                            "id": <integer>,
                                                            "name": <string>
                                                    }
                    },...],
                    "pool_created": <boolean>
                },
                "l7_rule": {
                    "id": <integer>,
                    "tipo_opcao": <string>,
                    "nome_opcao_txt": <string>
                },
                "l7_value": <integer>,
                "order": <integer>
            }]
        },...],
        "options": {
            "cache_group": {
                "id": <integer>,
                "tipo_opcao": <string>,
                "nome_opcao_txt": <string>
            },
            "traffic_return": {
                "id": <integer>,
                "tipo_opcao": <string>,
                "nome_opcao_txt": <string>
            },
            "timeout": {
                "id": <integer>,
                "tipo_opcao": <string>,
                "nome_opcao_txt": <string>
            },
            "persistence": {
                "id": <integer>,
                "tipo_opcao": <string>,
                "nome_opcao_txt": <string>
            }
        },
        "groups_permissions": [{
            "group": {
                "id": <integer>,
                "name": <string>
            },
            "read": <boolean>,
            "write": <boolean>,
            "change_config": <boolean>,
            "delete": <boolean>
        },...],
        "created": <boolean>
    },...]
}

Using fields and kind together¶

If fields is being used together kind, only the required fields will be retrieved instead of default.

Example with details kind and id field:

kind=details&fields=id

Default behavior without kind and fields¶

If neither kind nor fields are used in request, the response body will look like this:

{
    "vips": [{
        "id": <integer>,
        "name": <string>,
        "service": <string>,
        "business": <string>,
        "environmentvip": <integer>,
        "ipv4": <integer>,
        "ipv6": <integer>,
        "ports": [{
            "id": <integer>,
            "port": <integer>,
            "options": {
                "l4_protocol": <integer>,
                "l7_protocol": <integer>
            },
            "pools": [{
                "id": integer,
                "server_pool": <integer>,
                "l7_rule": <integer>,
                "l7_value": <integer>,
                "order": <integer>
            }, ...]
        }, ...],
        "options": {
            "cache_group": <integer>,
            "traffic_return": <integer>,
            "timeout": <integer>,
            "persistence": <integer>
        },
        "created": <boolean>
    },...]
}

Creating list of vip request¶

URL:

/api/v3/vip-request/

Request body:

{
    "vips": [{
        "business": [string],
        "created": [boolean],
        "environmentvip": [environmentvip_id],
        "id": [null],
        "ipv4": [ipv4_id],
        "ipv6": [ipv6_id],
        "name": [string],
        "options": {
            "cache_group": [optionvip_id],
            "persistence": [optionvip_id],
            "timeout": [optionvip_id],
            "traffic_return": [optionvip_id]
        },
        "ports": [{
            "id": [vip_port_id],
            "options": {
                "l4_protocol": [optionvip_id],
                "l7_protocol": [optionvip_id]
            },
            "pools": [{
                    "l7_rule": [optionvip_id],
                    "l7_value": [string],
                    "order": [integer],
                    "server_pool": [server_pool_id]
                },..],
            "port": [integer]
            },..],
        "service": [string]
    },..]
}

• “environmentvip” attribute is an integer that identifies the environment vip that is desired to associate to the new vip request.

• “options” are the configured options vip that is desired to associate to the new vip request.

  • cache-group, persistence, timeout and traffic_return are some values present in the database. These values are configured to a set of restricted values.

• “ports” are the configured ports that is desired to asssociate to the new vip request.

  • l4_protocol and l7_protocol in options and l7_rule in pools work as well as the values present in “options” discussed above.
  • “server_pool” is the identifier of the server-pool port associated to the new vip request.

URL Example:

/api/v3/vip-request/

More information about the POST request can be obtained in:

/api/v3/help/vip_request_post/

Updating list of vip request in database¶

URL:

/api/v3/vip-request/[vip_request_ids]/

where vip_request_ids are the identifiers of vip requests. It can use multiple ids separated by semicolons.

Example with Parameter IDs:

One ID:

/api/v3/vip-request/1/

Many IDs:

/api/v3/vip-request/1;3;8/

Request body:

{
    "vips": [{
        "business": [string],
        "created": [boolean],
        "environmentvip": [environmentvip_id],
        "id": [vip_id],
        "ipv4": [ipv4_id],
        "ipv6": [ipv6_id],
        "name": [string],
        "options": {
            "cache_group": [optionvip_id],
            "persistence": [optionvip_id],
            "timeout": [optionvip_id],
            "traffic_return": [optionvip_id]
        },
        "ports": [{
            "id": [vip_port_id],
            "options": {
                "l4_protocol": [optionvip_id],
                "l7_protocol": [optionvip_id]
            },
            "pools": [{
                    "l7_rule": [optionvip_id],
                    "l7_value": [string],
                    "order": [integer],
                    "server_pool": [server_pool_id]
                },..],
            "port": [integer]
            },..],
        "service": [string]
    },..]
}

• “environmentvip” attribute is an integer that identifies the environment vip that is desired to associate to the existent vip request.

• “options” are the configured options vip that is desired to associate to the existent vip request.

  • cache-group, persistence, timeout and traffic_return are some values present in the database. These values are configured to a set of restricted values.

• “ports” are the configured ports that is desired to asssociate to the existent vip request.

  • l4_protocol and l7_protocol in options and l7_rule in pools work as well as the values present in “options” discussed above.
  • “server_pool” is the identifier of the server-pool port associated to the existent vip request.

URL Example:

/api/v3/vip-request/1/

More information about the PUT request can be obtained in:

/api/v3/help/vip_request_put/

Deleting a list of vip request in database¶

/api/v3/vip-request/[vip_request_ids]/

/api/v3/vip-request/1/

/api/v3/vip-request/1;3;8/

keepip=[0|1]

/api/v3/vip-request/1/

/api/v3/vip-request/1/?keepip=1

Deploying list of vip request in equipments¶

URL:

/api/v3/vip-request/deploy/[vip_request_ids]/

where vip_request_ids are the identifiers of vip requests desired to be deployed. These selected vip requests must exist in the database. vip_request_ids can also be assigned to multiple id’s separated by semicolons.

Examples:

One ID:

/api/v3/vip-request/deploy/1/

Many IDs:

/api/v3/vip-request/deploy/1;3;8/

Updating list of vip requests in equipments¶

URL:

/api/v3/vip-request/deploy/[vip_request_ids]

where vip_request_ids are the identifiers of vip requests desired to be updated. It can use multiple ids separated by semicolons.

Request body:

{
    "vips": [{
        "business": <string>,
        "created": <boolean>,
        "environmentvip": <environmentvip_id>,
        "id": <vip_id>,
        "ipv4": <ipv4_id>,
        "ipv6": <ipv6_id>,
        "name": <string>,
        "options": {
            "cache_group": <optionvip_id>,
            "persistence": <optionvip_id>,
            "timeout": <optionvip_id>,
            "traffic_return": <optionvip_id>
        },
        "ports": [{
            "id": <vip_port_id>,
            "options": {
                "l4_protocol": <optionvip_id>,
                "l7_protocol": <optionvip_id>
            },
            "pools": [{
                    "l7_rule": <optionvip_id>,
                    "l7_value": <string>,
                    "server_pool": <server_pool_id>
                },..],
            "port": <integer>
            },..],
        "service": <string>
    },..]
}

• “environmentvip” attribute is an integer that identifies the environment vip that is desired to associate to the existent vip request.

• “options” are the configured options vip that is desired to associate to the existent vip request.

  • cache-group, persistence, timeout and traffic_return are some values present in the database. These values are configured to a set of restricted values.

• “ports” are the configured ports that is desired to asssociate to the existent vip request.

  • l4_protocol and l7_protocol in options and l7_rule in pools work as well as the values present in “options” discussed above.
  • “server_pool” is the identifier of the server-pool port associated to the existent vip request.

URL Example:

/api/v3/vip-request/1;3;8/

More information about the PUT request can be obtained in:

/api/v3/help/vip_request_put/

Deleting list of vip requests in equipments¶

URL:

/api/v3/vip-request/deploy/[vip_request_ids]/

where vip_request_ids are the identifiers of vip requests desired to be deleted. It can use multiple id’s separated by semicolons. Doing this, the IP associated with each server pool desired to be deleted will also be deleted if this IP is not associated with any other vip request not contained in list of vip request that the user want to delete.

Example with Parameter IDs:

One ID:

/api/v3/vip-request/deploy/1/

Many IDs:

/api/v3/vip-request/deploy/1;3;8/

Obtaining list of vip request¶

/api/v3/vip-request/details/[vip_request_ids]/

/api/v3/vip-request/details/1/

/api/v3/vip-request/details/1;3;8/

{
    "vips": [{
        "id": (vip_id),
        "name": (string),
        "service": (string),
        "business": (string),
        "environmentvip": {
            "id": (environmentvip_id),
            "finalidade_txt": (string),
            "cliente_txt": (string),
            "ambiente_p44_txt": (string),
            "description": (string)
        },
        "ipv4": {
            "id": (ipv4_id)
            "ip_formated": (ipv4_formated),
            "description": (string)
        },
        "ipv6": null,
        "equipments": [{
            "id": (equipment_id),
            "name": (string),
            "equipment_type": (equipment_type_id),
            "model": (model_id),
            "groups": [(group_id),..]
        }],
        "default_names": [(string),..],
        "dscp": (vip_dscp_id),
        "ports": [{
            "id": (vip_port_id),
            "port": (integer),
            "options": {
                "l4_protocol": {
                    "id": (optionvip_id),
                    "tipo_opcao": (string),
                    "nome_opcao_txt": (string)
                },
                "l7_protocol": {
                    "id": (optionvip_id),
                    "tipo_opcao": (string),
                    "nome_opcao_txt": (string)
                }
            },
            "pools": [{
                "id": (vip_port_pool_id),
                "server_pool": {
                    'id': (server_pool_id),
                    ...information from the pool, same as GET Pool*
                },
                "l7_rule": {
                    "id": (optionvip_id),
                    "tipo_opcao": (string),
                    "nome_opcao_txt": (string)
                },
                "order": (integer|null),
                "l7_value": (string)
            },...]
        },...],
        "options": {
            "cache_group": {
                "id": (optionvip_id),
                "tipo_opcao": (string),
                "nome_opcao_txt": (string)
            },
            "traffic_return": {
                "id": (optionvip_id),
                "tipo_opcao": (string),
                "nome_opcao_txt": (string)
            },
            "timeout": {
                "id": (optionvip_id),
                "tipo_opcao": (string),
                "nome_opcao_txt": (string)
            },
            "persistence": {
                "id": (optionvip_id),
                "tipo_opcao": (string),
                "nome_opcao_txt": (string)
            }
        },
        "created": (boolean)
    },...]
}

:ref:`Django QuerySet API reference <https://docs.djangoproject.com/el/1.10/ref/models/querysets/>`_

/api/v3/vip-request/details/