The API is the new CLI.
If you’re a network engineer who pays attention to new technology, you’ve certainly heard some variation of this statement. But is it true?
Let’s start with the basics.
You know what a Command Line Interface (CLI) is; it’s how you talk to your switches and routers, and possibly many other devices and programs. An Application Programming Interface (API), on the other hand, defines the methods of communication between various software components. In other words, it’s how programs talk to each other.
In networking, there are probably three types of API that you’ll encounter: NETCONF, REST, and RESTCONF.
NETCONF
The Network Configuration Protocol (NETCONF – RFC 6241) “provides mechanisms to install, manipulate, and delete the configuration of network devices.” These are often called Create, Read, Update, Delete (CRUD) operations.
NETCONF uses a remote procedure call (RPC) model to communicate between clients—typically scripts or applications—with servers (the network devices). Clients send RPCs (requests) and network devices respond with RPC replies. While NETCONF is transport protocol agnostic, Secure Shell (SSH) is required to be supported, and is the most typically used. All configuration data and protocol messages (RPCs and RPC replies) are encoded using Extensible Markup Language (XML).
NETCONF uses a configuration lock to ensure that conflicting changes aren’t made simultaneously. This feature, along with the two-way (RPC) communication, can be leveraged to make atomic changes across an entire network of devices, ensuring “roll-back” to original state if changes fail on any of the devices.
In addition to configuration data, NETCONF also defines state data and allows network devices to send notifications to clients. This allows for network monitoring and telemetry-type data to be conveyed in addition to (or in support of) configuration changes.
REST
If you hang out around web developers, you’ve heard someone talk about RESTful APIs. REST is short for Representational State Transfer. While that sounds complex, the easiest way to think of it is “how the web works.” It’s defined in full detail in a PhD dissertation titled “Architectural Styles and the Design of Network-based Software Architectures” by Roy Thomas Fielding.
Essentially, RESTful or REST-like interfaces use the constructs of HTTP to communicate. Standard hypertext commands like GET, PUT, POST, DELETE are used. However, instead of a browser pulling down a webpage for you to view, we’re now using HTTP to communicate about any resource, potentially including network device configurations. And that brings us to our next API…
RESTCONF
RESTCONF (RFC 8040) is essentially just a RESTful implementation of NETCONF. In other words, RESTCONF is NETCONF based on HTTP(s). More accurately, it is “an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).”
Other changes include the fact that RESTCONF can encode data as either XML or JavaScript Object Notation (JSON). Many find JSON easier to read and work with than XML. RESTCONF also introduces the concept of an “event stream” which allows a client to subscribe to an ongoing asynchronous stream of NETCONF Event Notifications, enhancing telemetry capabilities somewhat.
Network devices can support NETCONF, RESTCONF, or both.
YANG
YANG (RFC 7950) is not an API, but it’s important to note here anyway. That’s because YANG is “a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.” That includes, of course, both NETCONF and RESTCONF.
So you have YANG, which is the data model (template) for formatting your data. Then you use either NETCONF or RESTCONF to encode that data with XML or JSON and send it to (or receive it from) network devices over SSH or HTTP(s). Clear as mud? Great. Back to the original question…
Is the API the new CLI?
As I hope you can see from the quick run-down above, APIs are very powerful tools for interacting with your network devices. They are specifically designed to allow programs to communicate reliably with network devices. These programs might be scripts that you write yourself to speed up common configuration or troubleshooting tasks. They might also be comprehensive intent based SDN controllers that abstract the individual network devices completely away and let you interface with the entire network as a single system.
This power and flexibility will surely make them a big part of every network, and so it’s important to be familiar with them. However, I don’t think we’ll see the CLI disappear any time soon, if at all. CLIs are still a great way for a human to interact with a single network device, and it’s likely that will be needed from time to time for a long time to come.
My take is that APIs are here to stay, but so is the CLI; it’s our job as engineers to learn both, and apply them each effectively.
This post first appeared on the Myriad blog.
