One of the most important aspects of network automation is to understand and leverage tools that are currently available for specific tasks. For example, this could be Splunk for data mining, SolarWinds for network monitoring, syslog servers, or even any custom applications to perform various tasks.
Another important aspect of writing an application is how we can utilize the same application for additional tasks without altering the application itself. In other words, let's say we buy a car for our personal use, but an enhancement of this would be using the same car as a taxi or in some other role.
This is we introduce the Application Program Interface(API). APIs are used to expose some aspect of an already written application to merge with the programs that we are writing so that we can easily call that specific task using a specific API. For example, as SolarWinds is a specialized application that is used for network monitoring and other purposes, we can call the API of SolarWinds to get the network device list in our script. Hence, we leave the specialized task of discovering the network devices on the network to SolarWinds, but we utilize its expertise in our script through the API of that application.
Getting a bit deeper, the API is nothing more than a function (similar to the functions that we write in our scripts); the only difference is what values those functions return. An API function generally returns the values in Extended Markup Language (XML) or JavaScript Object Notation (JSON) format, which are industry standards of cross-environment and cross-machine information exchange. Think of this as similar to how we communicate with each other using English as a common language. Although we may have been born in different cultures, in different countries, we can use English to communicate with each other effectively, since English is the industry standard of human interaction. Similarly, irrespective of how a program is written, in whatever language (such as C, C++, Java, VB, C#, and so on), each program can talk to another program by calling its APIs and the results come in either XML or JSON.
XML is a standard way of encoding results and sending them across to the requestor and, using the same standard, the requestor can decode the results. JSON is another way in which data interactions can happen across applications.
Here is sample XML:
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Readers</to>
<from>JAuthor</from>
<heading>Reminder</heading>
<body>Read this for more knowledge</body>
</note>The first line in the preceding content depicts that whatever follows after that line is in XML format. The XML files are saved with extension of .xml.
Now as we can see, if we count the number of characters returned from an XML result, if we add the characters, such as <heading>Reminder</heading>, it returns results within the starting tag and ending tag of <heading>. This means that the size of an XML file is greatly increased owing to the overhead character counts of additional closing tags.
Here's the same example in JSON:
{
"note": {
"to": "Tove",
"from": "Jani",
"heading": "Reminder",
"body": "Don't forget me this weekend!"
}
}As we can see, we have got rid of those extra bulky opening and closing tags that we saw earlier in XML. What this means is if we are calling an API to return a huge amount of data in XML format, it would certainly take a longer time to fetch that data from the application and more consumption of resources such as memory and storage to temporarily or permanently store that data. To overcome this situation, the JSON format is now preferred to XML to exchange data through APIs. JSON is lightweight and less resource-intensive than XML because of differences in the way the data is returned. JSON files are saved with the extension.json.
This functionality of working with APIs, back end methods, and functions written in a particular programming language to be called APIs, and functions returning values in XML or JSON format, all of which is running over web protocols such as HTTP or HTTPS, is cumulatively called the REST framework. The REST framework is the same industry standard of interacting using XML or JSON that were referenced earlier, with the addition of GET, POST, and other interactions happening over the web protocols. The HTTP requests to APIs can be GET or POST requests that the REST framework recognizes and, similar to HTTP GET and POST requests, interacts with underlying applications to perform the requested actions.
Scripting languages rely heavily on API calls, and applications that need to provide the API's functionality adhere to REST framework requirements to ensure they extend their capabilities to the scripts that are called to fetch or save data in their choice of scripting language. A big benefit of this is that cross-platform communication is now happening with neither party (the caller of API or the application providing the API's functionality) knowing which language or environment the other are running. Hence, a Windows application can easily work with a Unix environment and vice versa using this approach, with HTTP being the standard communication language for calling APIs, and parsing the results with industry standard XML or JSON formats.
The sample API REST call in PowerShell is as follows:
As we can see in the preceding screenshot, we call the Invoke-RestMethod function in PowerShell, which is used to call the API method of the application with the default communication and interactions using JSON.
The application called is in a REST framework, with access to the API with the URL https://blogs.msdn.microsoft.com/powershell/feed/. This uses the HTTPS protocol to communicate with the application.
format-table is a function of PowerShell that specifies that however the result comes, display the title property of each record/result returned from the API call. If we had not used that command, the display would have shown all the properties returned for each record.
Here's an example REST call in Python:
In this example, we call a standard function called requests. The first line, import requests, means that we are referencing the requests function or library to call in our Python script. On the next line, we are calling the Google Map API with JSON using a requests.get method. In other words, we are ensuring a HTTP GET call to the Google API URL. Once we get the result, we call the json() method to store the value in the variable r.
Note
Sometimes, when we call a custom function or library of Python using import, it may give an error stating that the module has not been found. This means that it does not come with the standard Python installation and needs to be installed separately. To fix this, we can install the module manually using the pip or easy_install commands, which we will see in detail in upcoming chapters.