Table of Contents
Introduction
Are you still configuring network devices through a black CLI window?
CLI is suitable for scenarios involving single devices, manual operations, or simple scripts. However, in today’s large-scale, heterogeneous, and multi-version network automation environments, CLI syntax and text output formats may change across vendors or even between different software versions from the same vendor. This makes scripts highly fragile and increases maintenance costs.
To address these challenges, NETCONF was introduced. NETCONF uses a standard protocol to configure, query, and modify network devices through XML-based data models. Although NETCONF provides powerful capabilities, many developers who are familiar with modern web development find its steep RPC learning curve, verbose XML encoding, and dependency on long-lived sessions difficult to adopt. With the evolution of SDN, cloud computing, and network automation, developers have become more accustomed to the HTTP + REST API + JSON development model.
Based on NETCONF and YANG, the IETF introduced RESTCONF (RFC 8040), which provides lightweight and standardized access to underlying YANG data models through a familiar RESTful style and JSON format.
What is NETCONF?
Let’s first review NETCONF, from its basic concepts to deployment methods.
Please refer to this article: What is Netconf ?How Does It Work on Enterprise SONiC Switches?
What is RESTCONF?
RESTCONF (Representational State Transfer Configuration Protocol) is a network management protocol defined by the IETF. It provides RESTful APIs over HTTP/HTTPS to access and manage network device configuration and operational data defined by YANG data models.
RESTCONF abstracts management objects on network devices as resources, such as interfaces, VLANs, routing entries, and BGP neighbors. External systems can use standard HTTP methods, including GET, POST, PUT, PATCH, and DELETE, to query, create, modify, and delete these resources.
The goal of RESTCONF is to expose network device management capabilities in a way that aligns better with modern Web API development practices. Compared with NETCONF, which uses an RPC-based operation model, RESTCONF focuses more on resource-oriented access and operations. It supports both reading configuration and operational state data, as well as modifying configurations and performing device operations through standard HTTP methods. This makes RESTCONF easier to integrate with web applications, automation platforms, and network orchestration systems.
RESTCONF has three main characteristics:
- Based on HTTP/HTTPS: Uses common web transport protocols, making it easier to integrate with existing tools and development frameworks.
- Based on YANG data models: Operations are performed on structured data trees instead of individual CLI commands.
- RESTful interface: Uses HTTP methods such as GET, POST, PUT, PATCH, and DELETE to operate on resources and datastores.
When understanding NETCONF and RESTCONF together, NETCONF is a network device management protocol where the client sends RPC requests to devices to perform configuration operations. RESTCONF, on the other hand, is an API interface that exposes device configuration and operational data defined by YANG models as HTTP-based REST resources. This allows external systems to manage network devices in the same way they interact with Web APIs.
How Does RESTCONF Work?
Let’s first identify the two parties involved in RESTCONF communication:
- Client: Usually an NMS, orchestrator, automation script, controller, Python program, or any software that calls RESTCONF APIs.
- Server: Usually a switch, router, or a RESTCONF service agent running on the device. It is responsible for storing and exposing configuration data and operational data, as well as processing client requests.
The core RESTCONF workflow can be summarized as follows:
The client establishes a secure HTTPS connection → discovers the data models supported by the device → locates YANG data resources through URIs → uses HTTP methods to operate on resources → the device maps requests to the YANG data tree and corresponding datastores → returns the response.
1. Establish a Secure Connection
RESTCONF operates over HTTPS.
First, the RESTCONF Client initiates an HTTPS session with the RESTCONF Server running on the device.
During this process:
- TCP establishes the connection.
- TLS performs authentication and key negotiation.
- Subsequent RESTCONF requests are transmitted through the encrypted HTTPS channel.
After the secure connection is established, the client can use HTTP requests to access device resources.
2. Read the Root Path
The client first retrieves the RESTCONF root path from the server, which serves as the entry point for accessing resources exposed by the server. At this stage, the client needs to understand which data models are supported by the server.
RESTCONF uses YANG Library and device capability information to help the client obtain the following information:
- Supported YANG modules.
- Module version information.
- Available data structures.
After obtaining this information, the client can construct RESTCONF URIs correctly, parse returned data, and determine which resources can be accessed or modified.
3. Locate Resources Through RESTCONF URI
The client accesses resources such as interfaces, VLANs, and routing entries based on the YANG data tree exposed by the server. RESTCONF URI is used to locate these resources. Each specific resource instance has an addressable URI path that can be used for query or modification operations.
4. Operate Data Through HTTP Methods
After the client locates the target resource through the RESTCONF URI, it uses the following HTTP methods to perform operations on these resources:
- GET: Retrieve resource data.
- POST: Create a new resource or invoke an operation.
- PUT: Replace an entire resource.
- PATCH: Modify part of a resource.
- DELETE: Delete a resource.
5. RESTCONF Maps Requests to YANG Data Trees and Datastores
After receiving a RESTCONF request, the RESTCONF Server processes the request by accessing the corresponding data resources. These resources are typically stored in different data views, known as datastores.
Common datastores include:
- Running: The active configuration currently applied on the device.
- Candidate: A configuration draft that requires a commit operation before taking effect.
- Startup: The configuration loaded when the device restarts.
- Operational/State: The current operational state, statistics, and interface status of the device.
6. Return Results to the Client
After processing the request, the server returns the result to the client. The response format is usually JSON or XML. The client can specify the preferred response format through the Accept header, making structured data such as JSON and XML easier to parse.
RESTCONF Benefits
Developer-Friendly and Low Learning Curve
- High familiarity with HTTP/HTTPS: Modern web developers and DevOps engineers are already familiar with REST APIs, including HTTP methods such as GET, POST, PUT, PATCH, and DELETE. They do not need to learn the complex XML-RPC mechanism used by NETCONF.
- Native JSON support: Compared with large XML payloads, JSON is lightweight and easier to process. It provides faster parsing and works naturally with mainstream programming languages such as Python, Go, and JavaScript.
Easier Integration
RESTCONF runs over HTTP/HTTPS and can be tested and debugged directly using mature HTTP API tools such as Postman, Insomnia, and cURL. For many engineering teams, this is easier to adopt than learning a new RPC session model.
Still Model-Driven
Although RESTCONF looks similar to a Web API, it is not a generic REST API. It is strictly based on YANG data models, which makes the API structure predictable, standardized, and extensible.
Lightweight and Resource-Efficient
Stateless interaction: RESTCONF uses the stateless HTTP protocol. Unlike NETCONF, it does not require long-lived SSH sessions or complex lock management. This reduces CPU and memory overhead on network devices and makes it suitable for small and medium-sized networks or lightweight operation and maintenance systems.
Standardized Security and Transport
RESTCONF runs over HTTPS, allowing its communication security mechanisms to align more easily with existing web security standards. Compared with traditional CLI-based management, RESTCONF is better suited for exposure to automation platforms and controllers.
RESTCONF vs. NETCONF Comparison
NETCONF and RESTCONF are both model-driven network management protocols. They use YANG to define and constrain network device data models. Their common goal is to make network device configuration and state data programmable and accessible in a structured format.
The main differences between them are the communication methods and interaction models. NETCONF typically runs over SSH and uses a session-based RPC interaction model, with XML as the primary data format. RESTCONF runs over HTTP/HTTPS and accesses resources through RESTful URIs and HTTP methods, while supporting both XML and JSON.
Compared with RESTCONF, NETCONF is more suitable for complex and transactional configuration management, while RESTCONF is better suited for web-native integration and lightweight automation.
The following table provides a detailed comparison:
| Dimension | NETCONF | RESTCONF |
| Protocol Stack | SSH | HTTP/HTTPS |
| Interaction Model | RPC / Session-based | REST / Resource-oriented |
| Data Encoding | XML | XML / JSON |
| State Model | Stateful | Stateless |
| Common Use Cases | Complex configuration, transactions, rollback | Web/API integration, lightweight automation |
| Access Method | Operates data through RPC operations | Operates resources through URIs and HTTP methods |
Using RESTCONF APIs to Manage Network Device Resources
After understanding how RESTCONF works internally, the next step is to understand how clients use RESTCONF APIs to manage device resources. A REST API manual typically provides detailed information about available endpoints, request parameters, HTTP methods, and response formats.
Please refer to RESTCONF API Manual
Asterfusion AsterNOS V6.1 Supports RESTCONF
RESTCONF support is available on CX-M series switches running AsterNOS V6.1R006P001.
Summary
As network operations evolve from traditional CLI-based management toward automation and intelligence-driven operations, the programmability of network devices has become a key requirement for modern data centers and enterprise networks.
- NETCONF provides a solid foundation for complex, transaction-based, and large-scale network orchestration through structured data modeling and secure configuration management.
- RESTCONF (RFC 8040) further bridges the gap between traditional network operations and modern Web/DevOps development practices. It combines the rigor of YANG model-driven management with the simplicity of HTTP + REST + JSON, providing developers with automation interfaces that are easier to adopt, integrate, and use.
Asterfusion is committed to embracing the open networking ecosystem. Currently, CX-M series switches running AsterNOS V6.1 provide native RESTCONF support, helping enterprises build flexible, efficient, and standardized modern cloud-based network infrastructures.
