• Switch Login
  • USER: admin
  • PASS: cisco.123
  • staging-spine1: 10.15.9.11
  • staging-leaf1: 10.15.9.12
  • staging-leaf2: 10.15.9.13
  • prod-spine1: 10.15.9.14
  • prod-leaf1: 10.15.9.15
  • prod-leaf2: 10.15.9.16
  • NX-API Sandbox
  • GitLab Server
  • USER: pod09
  • PASS: c1sco.123
  • Gitlab
  • Nexus Dashboard
  • USER: admin
  • PASS: cisco.123
  • ND Web interface
  • Code-Server
  • Code-Server
RESTCONF
RESTCONF

Introduction to RESTCONF

Another transport mechanism to push configuration changes or read netowrk device configuration that uses YANG data models is the HTTP-based Representational State Transfer Configuration Protocol or RESTCONF. Like NETCONF, RESTCONF uses structured data to for YANG models to provide REST-like APIs. The structured data, again like NETCONF, can be represented as XML, but also allows the use of JSON.


RESTCONF Operations

Similar to NETCONF, RESTCONF uses standard HTTP operations. RESTCONF allows us to use standard GET, POST, PUT, PATCH, and DELETE methods in REST to manipulate and retrieve data backed by YANG models. Let's take a look at how operations on RESTCONF compare to NETCONF.


As a network programmer or software developer, RESTCONF is really convienient in the sense that REST is a very common interaction mechanism for making remote procedure calls (RPCs) to external systems using standard tooling. Applications like wget, curl, Postman, and Python's requests and urllib3 are used by millions of developers every day for interacting with REST based systems. As such they are hardened to the point that the toolchains for interacting with RESTCONF are very well documented and "searchable"; a developer looking to learn more about REST has the support of the entire internet behind them because it is such a common protocol.


RFC 8040 - RESTCONF Protocol

RESTCONF has been in discussion among major players since 2014, however the RFC was just ratified for publication as recently as January 2017. Please read the RFC's introduction as it provides a great overview. 

                        1.  Introduction

            There is a need for standard mechanisms to allow Web applications to
            access the configuration data, state data, data-model-specific Remote
            Procedure Call (RPC) operations, and event notifications within a
            networking device, in a modular and extensible manner.

            This document defines a protocol based on HTTP [RFC7230] called
            "RESTCONF", for configuring data defined in YANG version 1 [RFC6020]
            or YANG version 1.1 [RFC7950], using the datastore concepts defined
            in the Network Configuration Protocol (NETCONF) [RFC6241].

            NETCONF defines configuration datastores and a set of Create, Read,
            Update, Delete (CRUD) operations that can be used to access these
            datastores.  NETCONF also defines a protocol for invoking these
            operations.  The YANG language defines the syntax and semantics of
            datastore content, configuration, state data, RPC operations, and
            event notifications.

            RESTCONF uses HTTP methods to provide CRUD operations on a conceptual
            datastore containing YANG-defined data, which is compatible with a
            server that implements NETCONF datastores.

            If a RESTCONF server is co-located with a NETCONF server, then there
            are protocol interactions with the NETCONF protocol; these
            interactions are described in Section 1.4.  The RESTCONF server MAY
            provide access to specific datastores using operation resources, as
            described in Section 3.6.  The RESTCONF protocol does not specify any
            mandatory operation resources.  The semantics of each operation
            resource determine if and how datastores are accessed.

            Configuration data and state data are exposed as resources that can
            be retrieved with the GET method.  Resources representing
            configuration data can be modified with the DELETE, PATCH, POST, and
            PUT methods.  Data is encoded with either XML [W3C.REC-xml-20081126]
            or JSON [RFC7159].

            Data-model-specific RPC operations defined with the YANG "rpc" or
            "action" statements can be invoked with the POST method.  Data-model-
            specific event notifications defined with the YANG "notification"
            statement can be accessed.
Bash

Navigate here for the full RFC if you are interested in learning more.


A Useful Visual

When working with YANG models over RESTCONF, a key concept is to understand how the URL specified maps to the underlying YANG model being accessed.

Later in this section of the lab you will use the concepts presented in this visual to apply configuration using YANG models.