Although automation can take form in a non-programmatic way, we cannot examine it without talking about API.
In this blog post, we discuss automation further. Now that we’ve established an understanding from a business and operations standpoint, as well as have seen the real-world impact of automation, it’s time to dive deeper.
Although automation can take form in a non-programmatic way (such as through a GUI), we cannot examine it without talking about API. After all, automation is at its best when it’s, well, automated. (And hidden from the end-user.)
The word nowadays has come to refer colloquially to specific use cases (such as automation), most often in the context of web services, but APIs can be used for anything. API stands for “Application Programming Interface” and is simply the concept of exchanging data.
API is just an abstraction. When you’re using an application on your phone or computer, you connect to API endpoints of the operating system in order to communicate with the system. When you look up an address in Google Maps, a database entry in SQL, or just posting a comment on a website — all you do is send and receive data (text, more often than not) through APIs.
Because API can mean lots of different things, depending on the context, let’s focus on our expertise: DNS, DHCP, and IP address management.
In IP infrastructure automation, APIs are used to communicate with web services in the same way: pulling and pushing data. You can pull DNS zone information from Azure, send it to Akamai Fast DNS, ask about the DHCP leases on your Cisco router, or find the first available IP address in a subnet on your corporate network — all through the API. Even the user interface for the Men&Mice Suite is “just” a graphical frontend for the API.
Let’s take a look at what kind of API.
When we talk about APIs in this quite specific context, we usually mean SOAP or REST. The Men&Mice Suite, in particular, uses the SOAP API to do its magic internally but provides a REST API for users as well.
What’s the difference?
For one thing, SOAP is a protocol, while REST is an architectural style. But let’s not get ahead ourselves.
SOAP was initially developed by Microsoft during the ‘90s. It was meant to replace older, binary protocols (like DCOM and CORBA) that didn’t play nice with the internet’s emerging new technologies. The specification was submitted to the IETF for standardization and became a W3C recommendation in 2003.
SOAP is and was always considered to be a standard. Thus, it is subject to many rules and incorporates much built-in (as well as extended) functionality. This can be good because a SOAP implementation will always have all functionality that doesn’t vary from vendor to vendor, but also means it requires more resources and is slower.
REST was developed in parallel with HTTP itself. Therefore it’s usually considered to be more suitable for services that use HTTP and is highly reliant on the protocol.
As an architectural style, and not a standard, REST requires only a set of six guidelines to be satisfied; the rest is up to the implementation. These guidelines are: client-server architecture, statelessness, cacheability, code on demand, layered system, and uniform interface.
REST is highly embedded in the “texture” of the internet through HTTP. It uses SSL for security. It can accept not only XML input, but also HTML, JSON, and YAML. Because REST doesn’t have strict rules to follow, sometimes implementation can be a hit-and-miss regarding security or functionality.
As we said, the Men&Mice Suite does its magic through SOAP. Not because we have anything against REST — we love it, in fact, and offer a REST API to use — but because it was available when we started. (We're old, did you know?)
REST is flexible, fast, and simple. It’s data-driven, stateless, and can cache API calls. On the other hand, REST can only use the HTTP protocol and is less secure (relies on SSL). SOAP can use multiple protocols, with built-in security. It’s function-driven, stateless but can be used stateful, and doesn’t cache API calls.
Depending on the use case, either can perform better. For public consumption, REST is generally considered to be better. Enterprise applications, however, or those requiring more functionality, will be better off with SOAP.
First we learned what automation is and how it can help us (see our first post in this series), and now, we know which APIs IP infrastructure automation usually employs.
In our next two posts, we’ll go deeper into both: one for REST and one for SOAP, with more focus on each. By the end, you’ll be able to construct API calls for both, and decide which one to use in your own environment. (Or how to use both.)