To API or Not To API

One of my readers left this comment (slightly rephrased) on my Network Automation RFP Requirements blog post:

Given that we look up to our *nix pioneers as standard bearers for system automation, why do we demand an API from network devices? The API requirement would make sense if the vendor OS is a closed system. If an open system vendor creates APIs for applications running on their system (say for BGP configs) - kudos to them, but I no longer think that should be mandated.

He’s right - API is not a mandatory prerequisite for reliable network automation.

Getting started with network automation? My online course might be just what you need.

It doesn’t matter (from the reliability perspective) whether you make changes to a system configuration by modifying a text file and reloading the configuration, by running a CLI command, or by executing an API call. What does matter is that:

  • The change operation returns a well-defined and easy-to-detect OK/FAIL status;
  • The FAIL status includes an easy-to-detect error message;
  • The changes done through any of the above methods are atomic (all-or-nothing);
  • You can change many parts of the configuration in a single atomic transaction.
Anyone who cut himself off a router while configuring an access list should be very familiar with the last requirement.

While Linux or Windows CLI commands usually meet most of these requirements (exit codes, error messages sent to STDERR), many networking devices don’t come even close.

Moving from system configuration to operational data: while it’s not mandatory that the system returns operational data as structured data in easy-to-parse presentation format (XML or JSON), it helps immensely if it does, and Linux CLI is often no better than the stuff we have to deal with on networking devices. Linux forums are littered with arcane pipelines of commands that resemble line noise but produce exactly what you need if you ever master to understand how to tweak them.

APIs have obvious benefits over CLI commands, for example exposing just the functionality you want third parties to consume, but in the context of minimum mandatory requirements API is really just a highly appreciated convenience mechanism. It’s so much easier for a programmer to execute an HTTP(S) GET or POST request than logging into the box via SSH and executing CLI commands or trying to figure out how to spell NETCONF.

Latest blog posts in CLI versus API series


  1. The remainder of the original comment rephrased here was,"...Something like Ansible could be the 'API broker' for higher level workflow tools, to interact with the services on that platform...."

    Given the context of this extended comment, I think I may have to disagree and assert that an API (or something like it) should be required. (Maybe I'm just misunderstanding the "open" vs "closed" system piece?)

    Driverless vehicles come to mind. As ain initial POC, maybe the steering wheel, accelerator, brakes, and gear selectors are fitted with clunky "sticks and servos", engineered to dial in just the right combination of kinetic output to command the vehicle. In practice, however, such modifications would be more tightly integrated with the underlying controlling mechanisms, instead of struggling to control the abstractions.

    While something like Ansible as an "API broker" might be a feasible short- to mid-term solution, might we not be incurring more technical debt in the future by being so loose on the standards requirements in the present?
  2. Hi! Why don't you like NETCONF so? It's standard protocol, but API is like SNMP MIB. Every vendor does it like it's want. Am I right?
    1. NETCONF is API (actually the session layer). API != HTTP (REST).

      As for what NETCONF really is: The data models are slowly being implemented by some vendors (see

      It's about time the networking engineers wake up and realize NETCONF+YANG is not an aspirin.
Add comment