CLI or API… Again (and Again and Again…)

Got this comment on one of my blog posts:

When looking at some of the CLIs just front-ending RESTAPIs, I wonder if "survival" of CLI isn't just in the eyes of the beholder.

It made me really sad because I wrote about this exact topic several times… obviously in vain. Or as one of my network automation friends said when I asked him to look at the draft of this blog post:

This topic is one that's been beaten to death, dragged behind a tractor, resurrected, burnt, buried, dug up, set on fire again and then thrown out to sea.

Sometimes I wonder whether it’s worth wasting everyone’s time trying to debunk vendor myths.

Background Reading

Anyway, here are a few things I wrote on the topic. You might want to read them first ;)

Back to CLI versus API

Coming back to the comment. Is CLI a living dead and kept alive only because grumpy old men continue to use it? How about this:

  • Having API is great if you need access to a device/system/software package/car/whatever from upstream orchestration/provisioning system;
  • Humans don't cope well with program-to-program APIs like REST or gRPC. Whenever you need to touch the box/system/… directly you’d wish for a CLI before completing the first curl command. Just ask anyone who’s old enough to remember Wellfleet Technician Interface;

In short: a CLI which talks to the API allows humans to tweak and optimize the systems directly (without going through an umbrella orchestration system UI) without the human being bogged down with the minutia of URL components, HTTP cookies, or JSON syntax.

Not surprisingly, having CLI sitting on top of API for operator’s convenience is a long-standing (and pretty successful) practice. Why do you think Junos had this option for 15 years, or why there are CLI versions of AWS or OpenStack API?

For Those Few that Actually Care

Nothing I write here will nudge the marketers or social media experts a tiny bit. They live in a different reality. You could continue drinking vendor their KoolAid and enjoying quotes that have no touch with reality, or you could decide to take the red pill: consume some quality structured content that will teach you how things get done.

There are plenty of good choices out there, including my NetOps webinars, Building Network Automation Solutions online course, excellent presentations from David Barroso, Mircea Ulinic, the Facebook team and many others, most of them listed in Awesome Network Automation GitHub repository.

Latest blog posts in CLI versus API series


  1. >>Wellfleet Technician Interface
    Do you mean that Wellfleet SNMP-based GUI management stuff?
    Looked nice, but gosh, that was slow as hell! But and it's still there, Nokia & Siemens used it for its DSLAMs and afaik it still lives in the now-Adtran DSLAMs. Another one were the good old BayStacks, may they R.I.P. ;-)
    1. No, the low-level CLI that you can access directly on the box ;)
  2. There are 2 type of APIs. One that is more for humans. Using JSON or YAML. This is as slow as a CLI. Good for a few commands, quasi static configurations, but not for large scale SDN.

    And binary APIs that could be fast and scalable. These are not human readable. This is not the fashion now. Or we call them as protocols and not API. Such OF, PCEP, DLEP, FlowSpec, etc.

    For the former, the CLI is still better for humans than using RESTCONF. And trade unions might still insist on TL1... :-)

    For me the real question is more like this: what is your tasks? Just some static configuration or real-time control? If we call it CLI, API, whatever is secondary to me.
Add comment