In Chapter 5, Low-Level Network Device Interactions, we looked at ways to interact with the network devices using Pexpect and Paramiko. Both of these tools use a persistent session that simulates a user typing in commands as if they are sitting in front of a Terminal. This works fine up to a point. It is easy enough to send commands over for execution on the device and capture the output. However, when the output becomes more than a few lines of characters, it becomes difficult for a computer program to interpret the output. The returned output from Pexpect and Paramiko is a series of characters meant to be read by a human being. The structure of the output consists of lines and spaces that are human-friendly but difficult to be understood by computer programs. 

In order for our computer programs to automate many of the tasks we want to perform, we need to interpret the returned results and make follow-up actions based on the returned results. When we cannot accurately and predictably interpret the returned results, we cannot execute the next command with confidence. 

Luckily, this problem was solved by the internet community. Imagine the difference between a computer and a human being when they are both reading a web page. The human sees words, pictures, and spaces interpreted by the browser; the computer sees raw HTML code, Unicode characters, and binary files. What happens when a website needs to become a web service for another computer? The same web resources need to accommodate both human clients and other computer programs. Doesn't this problem sound familiar to the one that we presented before? The answer is the Application Program Interface (API). It is important to note that an API is a concept and not a particular technology or framework, according to Wikipedia.

In our use case, the set of clearly defined methods of communication would be between our Python program and the destination device. The APIs from our network devices provide a separate interface for the computer programs. The exact API implementation is vendor specific. One vendor will prefer XML over JSON, some might provide HTTPS as the underlying transport protocol, and others might provide Python libraries as wrappers. Despite the differences, the idea of an API remains the same: it is a separate communication method optimized for other computer programs. 

In this chapter, we will look at the following topics:

• Treating infrastructure as code, intent-driven networking, and data modeling
• Cisco NX-API and the application-centric infrastructure
• Juniper NETCONF and PyEZ
• Arista eAPI and PyEAPI