Forum Discussion

Martin_Klein_10's avatar
Martin_Klein_10
Icon for Nimbostratus rankNimbostratus
Jan 12, 2014

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

  • BinaryCanary_19's avatar
    BinaryCanary_19
    Historic F5 Account
    Interesting observations. Considering that the REST API is early access at the moment, it might be a good idea to raise a support case to get this validated and sent up the right channels.
  • I have also noticed an issue with applying 'persist' to the VIP on 11.4.1 HF3. Also appears that the command 'tmsh modify /cli global-settings service number tmsh save sys config partitions all' has no effect on the returned service port string versus number.

     

  • 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 selfLinks and References are pointing back to the iControl REST interface, not to any VIP-specific property. These are references for (directly) accessing sub-components of the virtual (profiles and policies).

    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.

    This mapping comes from /etc/services. You should be able to change this behavior with the following TMSH command:

    tmsh modify sys db bigpipe.displayservicenames value true
    

    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?

    I don't know that this is true:

    curl -k -u admin:admin -X GET https://x.x.x.x/mgmt/tm/ltm/virtual?\$filter=partition%20eq%20test
    

    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?

    See above syntax.

    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 ?

    Absolutely agree here. You would need to infer the object type from its name (assuming you used a standard naming convention for objects).

  • Im working with 11.6, and having some issues determining the clientssl that is attached to the VIP. How would you link the virtual profile to the clientssl from REST?