A reader sent me this question:
I am hearing a lot about API in reference to SDN. I do not have any software or programming background but would like to understand this API in practical way. Could you help me?
More seriously, API stands for Application Programming Interface – a definition how programs (or clients) could use a library (or a server). Sometimes it’s as easy as defining functions a program can call, the parameters those functions accept, and the acceptable values of those parameters.
For example, when a C program wants to open a file, it calls the open function, which accepts a file name, and the way the file should be opened (Could the program write into the file? Should the file be created if it doesn’t exist?).
It seems Cisco’s OnePK follows this path – it defines a large number of functions that a Java program can call to influence Cisco IOS behavior, either on the local device (if you somehow manage to run Java on a Cisco’s box) or on a device to which the Java program has previously connected using yet-another function call.
Client-server APIs usually use a request-response protocol, where the client encodes its function call into whatever protocol message, sends the message to the server, which executes the call, and returns the results of the function back to the client.
One of the beauties of the REST API is that you can use Unix/OSX command line utilities like curl to execute function calls on a remote device.
For example, you can use REST API to configure an Arista switch. Instead of logging into the switch and typing show ip interface, your network configuration program could execute the following HTTP request:
Junos had similar functionality for years, but it’s not as easily accessible as REST API. They use NETCONF and XML, and neither one of them is exactly a mainstream programming technology these days.
Obviously there’s no need for the API to mirror the CLI functionality. The features available through the API could be totally different from the CLI commands, or a small subset of them (Arista is adding new commands to their eAPI with every EOS release). The API could also work on the control plane (Cisco’s OnePK seems to have functionality along those lines), or allow you to plug your code straight into the data plane (like F5 iRules).