Since the publication of the first edition of this book, the term Intent-Based Networking has seen an uptick in use after major network vendors chose to use it to describe their next-generation devices. In my opinion, Intent-Driven Networking is the idea of defining a state that the network should be in and having software code to enforce that state. As an example, if my goal is to block port 80 from being externally accessible, that is how I should declare it as the intention of the network. The underlying software will be responsible for knowing the syntax of configuring and applying the necessary access-list on the border router to achieve that goal. Of course, Intent-Driven Networking is an idea with no clear answer on the exact implementation. But the idea is simple and clear, I would hereby argue that we should focus as much on the intent of the network and abstract ourselves from the device-level interaction. 

In using an API, it is my opinion that it gets us closer to a state of intent-driven networking. In short, because we abstract the layer of a specific command executed on our destination device, we focus on our intent instead of the specific commands. For example, going back to our block port 80 access-list example, we might use access-list and access-group on a Cisco and filter-list on a Juniper. However, in using an API, our program can start asking the executor for their intent while masking what kind of physical device it is they are talking to. We can even use a higher-level declarative framework, such as Ansible, which we will cover in Chapter 4, The Python Automation Framework – Ansible Basics. But for now, let's focus on network APIs.