CLI or API? Wait … Do You Really Have to Ask?

The “Is CLI In My Way … or a Symptom of a Bigger Problem” post generated some interesting discussions on Twitter, including this one:

One would hope that we wouldn’t have to bring up this point in 2014 … but unfortunately some $vendors still don’t get it.

Why Is the CLI or API a Silly Dilemma?

A reasonably sound management plane implementation would have an object model (think SNMP MIB on steroids) that you could manipulate with CLI or API, and that the control-plane protocols would use to adjust their behavior. A simplistic object model would be just a tree of variables, a more thought-out one would use object-oriented programming with getter and setter functions.

Similarly, the state of the control-plane protocols (example: OSPF adjacencies, STP root bridge …) would be stored in a similar structure that any other process could access through a well-defined interface.

Once you have such an object model, it becomes trivial to implement CLI, REST API with JSON or XML, NETCONF API with XML, or any other data manipulation protocol (like OVSDB or even SNMP) – you just need a generic translation layer that maps external requests into GET or SET calls on internal objects.

The State of Networking Reality

How many vendors have an API call for every CLI command (or vice versa)? How many vendors can give you the same control-plane state or data-plane counters that you can inspect with CLI commands in an XML- or JSON-formatted response?

Junos definitely meets these requirements. Nexus OS NX-API and Arista EOS eAPI might be decent, but I never checked the feature parity between API and CLI.

On the other hand, Cisco IOS implementation of NETCONF fell far short of these goals the last time I checked (it was mostly screen scraping on steroids), IOS XR is better, but I’m not sure how far it goes (comments welcome). What about other vendors? Share your experience in the comments!

But Isn’t That Extra Work?

Of course it is if you have “suboptimal” software architecture … but if you did it right from the very beginning, every single CLI command should be accessible as an API call and vice versa. Also, adding the full-blown functionality isn’t hard – you get most of what you need with Tail-f’s ConfD (but of course that doesn’t work if you’re infected with the Not Invented Here plague).

Oh, and before anyone mentions increased testing requirements – if you don’t have an automated testing mechanism that would test CLI and API access to every object exposed by your software, you have a much bigger problem on your hands.

Does This Matter?

You might think that I’m discussing the maximum number of angels that can dance on a pinhead, but do consider that you might have to implement programmatic access to the devices you’re buying today in a few years (and roadmaps aren’t exactly helpful when you have to roll out something tomorrow).

Also, lack of CLI-API parity (particularly in the case of CLI being richer than API) might be an indication of vendor’s focus or the product’s software architecture. Whenever you encounter a recently-designed product with poor API be vary, proceed carefully, and vote with your budget.

Latest blog posts in CLI versus API series


  1. I have a IP PBX, it use only webgui, but.... The core engine has API, accessible for everybody. PBX wegui is usage example of this API. This way of thinking protects them against bad API implementation.
  2. If I have an Api I can code the CLI I like. Even configuting Devices via XMPP and your favourite jabber client could be possible. No command completion but how cool would that be? or irc. All devices of a single group join a specific channel. i.e. all 6500 Switches to #6500 and I can execute a command in the channel or do a private chat with each device and I'm sure there is an infinite number of ideas on what to do with an API. I don't think this is a real quwstion. it is already answered
    1. Every time there's a great idea, someone already implemented it ;)) Arista EOS has XMPP client which does exactly what you'd like to do.
  3. Great blog again, Ivan. I agree, it would be nice if the CLI and API aligned and "did objects". Given the history of the CLI in certain (many?) products, there's some serious retrofitting likely needed. Historically, hardware / assembly language schooled programmers don't think in object-oriented code.

    With Cisco's OnePK, I keep wondering if the API is going to have the same semantic drift that the IOS CLI does (similar commands but different results on different hardware platforms).
  4. @Pete - Be careful what you ask for on CLI/API alignment. CLIs are for humans and may arrange data differently than an API would for a computer. Maybe the requirement should be that one ought to be able to completely control the device with either interface without resorting to the other. Those who do not remember the lessons of Bay Networks' "Technician Interface" are doomed to repeat its poor choices. Same comments apply, mutatis mutandis, to TL1.
  5. Lol, this post slipped through my reader. Great as usual. APIs and networking is comical at the moment. While networking vendors haggle over what form of religion to use for RPC transport and modeling language, both of which should be irrelevant implementation detail, OpenStack continues to define every NaaS API imaginable.

    Personally what I still see missing is a decent GUI. APIs are great for provisioning but debugging/tshooting the network with APIs is a recipe for pain. Any of the hyperscale shops doing early SDN that I have spoken with have plenty of pain on that front. Hell, Vmware took commodity hypervisors and put a decent GUI on it and poof. Same for wireless controllers, UC platforms etc. I just need to find time to write some crappy GUI. :) Also, v6 and CLIs? I guess DNS can alleviate some of the pain but UUIDs and CLIs that would be great to hand type when the DC is down. Whatever we do, I just hope its totally unique to networking just to make a mess of it :) Disclaimer I work for RedHat etc.

    You the man Ivan. Maximum Angels per/Pinhead MAP per/sec lolz .
Add comment