In the last post, we went over NETCONF and how it can be used with YANG data models. In today’s post, we will be covering another very popular protocol called RESTCONF which is not as old or feature rich as NETCONF but is developed keeping in mind the requirements of modern API based systems and can still be used with YANG models. The table of contents is listed below. You can click on the link to jump to a relevant section.

1. Introduction
2. What is RESTCONF ?
3. RESTCONF Request Structure
4. Testing with Postman
5. Next in Line

Introduction

I’ve reproduced the diagram from my introductory post on Model Driven Programmability (MDP) that lists some of the major components of the MDP architecture. In the previous article, we discussed how a request containing an XML payload based on a YANG Data Model can be transmitted over a standard SSH connection using NETCONF protocol. In today’s post, we will be working with the same YANG model but the request will contain a JSON payload instead of an XML one and it will be sent over HTTPS instead of SSH. The final transmission will happen using RESTCONF protocol.

Before we delve further into RESTCONF & YANG, an important clarification needs to be made vis-a-vis its older & more mature counterpart NETCONF. The term NETCONF encompasses two different contexts. One context pertains to the following read/write operations on the network device that can be performed using NETCONF protocol. The second but often not discussed enough, context pertains to the work it does behind the scenes. It defines configuration datastores which then can be read from or written into using the following NETCONF operations.

• get-config
• edit-config
• copy-config
• delete-config
• lock
• unlock
• close-session
• kill-session

What is RESTCONF ?

As per RFC8040, RESTCONF is

An HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).

I’d like the readers to pay close attention to the definition given above. It says that RESTCONF simply provides an HTTP based mechanism to access the datastores which are originally defined by NETCONF. Sometimes, people get confused upon reading RESTCONF and NETCONF in the same breath because they think of these 2 as different protocols. However, as I’d mentioned in my note above, NETCONF is not just a communication protocol. It is also the main entity that defines the structure of configuration datastores. I like to refer to it as the “Datastore Manager” although there is no such official term. It is this “Datastore Manager” side of NETCONF which is being referred to in the RESTCONF RFC definition.

As the name suggests, RESTCONF works on the principles of standard REST architecture. This means that we can perform the same type of operations (GET, PUT, POST, DELETE) through RESTCONF as we could through any other REST API. RESTCONF is not intended to replace NETCONF, but rather to provide an HTTP interface that follows REST Architecture principles. I am linking one of my earlier articles here where I had explained what REST APIs are, what their HTTP methods are and how tools like Postman can be used to exploit their functionalities.

Understanding Postman – REST API & Cisco Unity Connection

RESTCONF Request Structure

Since RESTCONF relies on HTTPS as a transport protocol, it needs a URL to locate the resource on the network device. The basic structure of a RESTCONF request URL is given below

https://<device-address>/restconf/data/<yang-module>:<container>

This is the basic format of a RESTCONF request URL. The text which is in bold and italics is dynamic and will vary depending upon where & what you are trying to access. Let’s dissect it bit by bit.

• Address : This is the address of the device where RESTCONF server component is running. In the context of Network Management, it is most likely going to be the IP address of the Network Device.
• Yang-Module : The name of the YANG Data Model that’s being used for interaction.
• Container : A YANG module is a collection of different nodes like containers, Lists, Leafs etc. You can check out this article for further understanding of YANG model nodes.

Testing with Postman

By now, it’s been made abundantly clear that RESTCONF abides by the principles of REST architecture, then why not work with it like any other standard REST API and understand its structure using Postman.

• Let’s build the actual RESTCONF URL as per it’s defined structure explained in the previous section. In order to make the distinction between NETCONF and RESTCONF easier, let’s stick to the same YANG model we used in the previous article with NETCONF. Here is the link to the model

https://github.com/YangModels/yang/blob/main/vendor/cisco/xe/1761/openconfig-interfaces.yang

• The YANG Module is going to be “openconfig-interfaces” and Container is going to be “interfaces”. The final URL is given in the below screenshot. We will be performing a “Read” operation using HTTPS “GET” method.
• One can pretty much go with default headers and that should be enough. However, I decided to modify the “Accept” header to format data as JSON. It’s not required though.
• The device I am executing this URL against is a standard CSR1000V router in my lab running IOS XE.

• The following screenshot contains the output of above request. As you can see, the underlined statement shows the YANG model’s name and it’s primary container. Everything else is contained within it. The “interfaces” container shows information related to all the available interfaces on the device.

I hope that this brief demonstration was clear enough to highlight the advantage & simplicity that the combination of RESTCONF and YANG brings to the table.

---

Next in Line

This was my third post in this series on the concepts of Model Driven Programmability, the crux of which, relies on YANG Data Models. Although I have touched upon their usage and how to read them in the last three posts, it is quite possible that people may still find it difficult to understand their syntax. My next couple of posts are going to be dedicated towards explaining how one can simplify YANG models and use tools like YANG Suite to understand their syntax. So, stay tuned!!

Please feel free to provide your feedback/suggestions, if any.

Let’s connect on LinkedIn