Hands-On Lab: Configuring RESTCONF

Lab Objective

Enable RESTCONF on a router, retrieve interface configuration using a standard HTTP GET request, modify the interface description using an HTTP PATCH request, and verify the change through the CLI, comparing the overall workflow to NETCONF's approach from the previous lab.

Lab Purpose

NETCONF, covered in the previous lab, uses SSH transport and XML-formatted RPCs, requiring a NETCONF-aware client library. RESTCONF exposes the same underlying YANG-modeled configuration data through a standard HTTPS-based REST API using familiar HTTP verbs, making it accessible from any tool capable of making a basic HTTP request, including curl or a simple script with no specialized NETCONF library.

Lab Topology

R1 ---- Gi0/0: 192.168.255.1/24

Management station: 192.168.255.100,
using curl for RESTCONF interaction

Task 1: Enable RESTCONF on R1

Enable the RESTCONF service alongside the NETCONF service already configured in the previous lab.

Task 2: Retrieve Interface Configuration via HTTP GET

From the management station, issue a GET request to the RESTCONF API for the interface's configuration, requesting JSON format.

Task 3: Modify the Interface Description via HTTP PATCH

Issue a PATCH request updating the interface's description, sending a JSON payload.

Task 4: Verify the Change Through the CLI

Confirm the new description is visible through the traditional CLI.

Task 5: Compare the RESTCONF Workflow Against NETCONF

Note the differences in transport, request format, and tooling required between the two approaches.

Solution and Verification

R1(config)# restconf

-- RESTCONF and NETCONF, covered in the
-- previous lab, can run simultaneously,
-- since both simply expose the same
-- underlying YANG data model through
-- different transport and formatting
-- mechanisms

ManagementStation> curl -k -u admin:password \
  -H "Accept: application/yang-data+json" \
  https://192.168.255.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/0",
    "description": "",
    "enabled": true
  }
}
-- A plain HTTP GET request, authenticated
-- with basic credentials, returns the
-- exact same interface data NETCONF's
-- get-config RPC provided -- but reachable
-- with a tool as simple as curl

ManagementStation> curl -k -u admin:password -X PATCH \
  -H "Content-Type: application/yang-data+json" \
  -d '{"ietf-interfaces:interface":{"description":"Configured via RESTCONF"}}' \
  https://192.168.255.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0

-- HTTP 204 No Content
-- A 204 response confirms the PATCH was
-- accepted and applied -- the standard
-- HTTP status code for a successful
-- update with no response body needed

R1# show running-config interface gigabitethernet0/0

interface GigabitEthernet0/0
 description Configured via RESTCONF
 ip address 192.168.255.1 255.255.255.0
-- The description set via a simple curl
-- PATCH request is fully visible and
-- effective through the CLI

-- Comparison summary:

NETCONF: SSH transport, XML payloads,
         requires a NETCONF client library
         or specialized tool

RESTCONF: HTTPS transport, JSON (or XML)
          payloads, works with any standard
          HTTP client including curl,
          Postman, or basic scripting
          libraries in virtually any
          programming language

Key Takeaway

RESTCONF and NETCONF expose the identical underlying YANG data model, but RESTCONF's use of standard HTTPS and familiar HTTP verbs (GET, POST, PUT, PATCH, DELETE) makes it significantly more approachable for developers already comfortable with REST APIs, requiring no specialized client library the way NETCONF's SSH-based XML-RPC approach does — the choice between them typically comes down to what the automation toolchain in use already expects, rather than one being definitively superior to the other.