Using iControl-REST API

Hi,

we are using the iControl SOAP API for quite some time. For the next refactoring of our application we are very interested in the REST api to simplify things a little.

Looking through the responses on our LTM 11.4.1 some questions did arise as to its useability:

Example Response for a VirtualServer:

{
  "kind": "tm:ltm:virtual:virtualstate",
  "name": "servicemanager-443",
  "generation": 0,
  "lastUpdatedMicros": 0,
  "selfLink": "https:\/\/localhost\/mgmt\/tm\/ltm\/virtual\/servicemanager-443?$partition=\/iaas-prod\/",
  "partition": "\/iaas-prod\/",
  "autoLasthop": "default",
  "cmpEnabled": "yes",
  "connectionLimit": 0,
  "destination": "10.67.76.30:https",
  "enabled": null,
  "gtmScore": 0,
  "ipProtocol": "tcp",
  "mask": "255.255.255.255",
  "mirror": "disabled",
  "mobileAppTunnel": "disabled",
  "nat64": "disabled",
  "pool": "servicemanager-green",
  "rateLimit": "disabled",
  "rateLimitDstMask": 0,
  "rateLimitMode": "object",
  "rateLimitSrcMask": 0,
  "source": "0.0.0.0\/0",
  "sourceAddressTranslation": {
    "type": "automap"
  },
  "sourcePort": "preserve",
  "synCookieStatus": "not-activated",
  "translateAddress": "enabled",
  "translatePort": "enabled",
  "vlansDisabled": null,
  "vsIndex": 2,
  "persist": [
    {
      "name": "\/Common\/source_addr",
      "default": "yes"
    }
  ],
  "profilesReference": {
    "link": "https:\/\/localhost\/mgmt\/tm\/ltm\/virtual\/servicemanager-443\/profiles?$partition=\/iaas-prod\/"
  },
  "rulesReference": {
    "link": "https:\/\/localhost\/mgmt\/tm\/ltm\/virtual\/servicemanager-443\/rules?$partition=\/iaas-prod\/"
  }
}

• All HTTP URLs presented either as self link or Reference are not pointing to the hostname the request was made to but "localhost", which means before using them one needs to manually replace the host?

• The destination field contains the human readable protocol name for well known ports "destination": "10.67.76.30:https" instead of "destination": "10.67.76.30:443", which imho is questionable in an api, since one has to parse content which should already be machine readable.

• References to objects in the current partition, like pool in my example, are referenced witchout the path while objects in the common partition are referenced as /Common/object except when the current partion is /Common which seems a little inconsistent ?

• When passing the partiton as ?$partition=/name the api request returns the correct partition but when using the proper URL-Encoded string ?%24partition%3D%2Fname%0A the parameter is ignored and objects are always returned from the Common partition, which breaks a lot of rest api frameworks, since they tend to properly encode urls before passing them on to the HTTP handler?

*When calling the profilesReference one gets the folowing answer:

{
      "kind": "tm:ltm:virtual:profiles:profilesstate",
      "name": "servicemanager",
      "generation": 0,
      "lastUpdatedMicros": 0,
      "selfLink": "https:\/\/localhost\/mgmt\/tm\/ltm\/virtual\/servicemanager-443\/profiles\/servicemanager?$partition=
            \/iaas-prod\/",
      "context": "clientside"

}

With all profiles having the "kind": "tm:ltm:virtual:profiles:profilesstate" which means the answer does not contain any way to figure out which profile type it actually is, for example from this information it would not be possible to see if it is a ssl-client or a tcp profile, should this not give a list of profiles with refrerences to the actual profiles object ?

Are those issues known or is this simply the way the api should work?

Kind Regards

Martin