Don’t sweat the details!

Many networking systems vendors, including ECI, claim they support Intent-based RESTful APIs on their next generation management or orchestration systems. But what does this really mean? To answer, let’s parse the terms one by one.

APIs are application programming interfaces. They enable pieces of software dedicated to a purpose, that is to say applications, to communicate with each other. It is not important how the software is built whether using JavaScript, Python, or C++. The software is a black box. What is important is defining the command/query-response language that the API supports. Here are a few examples of using plain English.

We tend to think about transactions like these as human users, where we interact with the application through a GUI designed for humans. In reality, interaction with most applications can also take place on a machine-to-machine basis using APIs.

There are literally thousands of APIs that a developer can access. Popular locations you may want to check out are github.com or apilist.fun.

In fact, new terms entering the business lexicon are API Economy and API Ecosystem. These refer to how companies build businesses by creating applications, which at their core have a unique value add provided by that company, but for the greater part make use of APIs from many other companies. This enables tremendous efficiencies.

RESTful stands for Representational State Transfer. And that should be the first and last time you need to know that. For all practical purposes RESTful APIs use the same HTTP command structure that appears in your browser every time you interact with a web application.

For example, the second query above will look something like: https://maps.googleapis.com/maps/api/distancematrix/json?origins=Paris+France|Berlin+Germany&destinations (not a working link)

The response will come back in the way of a data structure that will be understood by the querying application, which can then make use of that information to continue its mission. For software developers in general, and web developers in particular, this stuff is like getting out of bed in the morning.

The words “intent-based” just means that the API (and its underlying application) works at a high level of abstraction. For example, let’s say you need to provision an e-line service between two endpoints of a business customer, with specific requirements for bandwidth, latency, and restoration time in the event of a failure. This actually requires many steps: getting a map of the network, evaluating and selecting primary and backup routes that meet the performance and availability requirements, assigning ports and updating VRF tables, and possibly testing the service before formally turning up.

Traditionally, applications would be written to go through these steps in detail. This would entail a lot of effort on both sides, the application based in an OSS requesting the e-line service, and the single or multiple applications providing the information and making the assignments.

With an intent-based API, however, all the details are hidden. A requesting OSS would simply specify the type of service, the end-points, and the performance requirements. The application supporting the intent-based API would perform all the necessary steps, update all the necessary databases, and return to the OSS with an equivalent of “mission accomplished.”

We are moving increasingly into world of intent-based APIs because they make life simpler, and for the most part can produce results which are near enough to being as optimum than if a process was broken down into many parts.

So in summary, the next time you see Intent-based RESTful APIs, just remember.

• API = WHAT you want to do.
• RESTful = HTTP-like protocol for HOW you do it.
• Intent-based = Interaction at a high-level of abstraction.

Or said another way, “Don’t sweat the details!”